CrossDCTest: Unable to load keys for caches that use UUID as key

[mhajas]

No description provided.

[mhajas]

There are two options

1. Use HotRod protocol to access the remote store with JBossMarshalling
2. Use Dataset provider functionality to access remote caches: https://github.com/keycloak/keycloak-benchmark/blob/main/dataset/src/main/java/org/keycloak/benchmark/cache/RemoteCacheResource.java

Option 2. is better, although it has some disadvantages like it is not secured and won't work if Keycloak is down.

[ahus1]

@mhajas - is this still necessary / still a problem? Can you add more context here if it is still necessary?

[mhajas]

Sure. Yes, this is still necessary in my opinion.

The issue here is that the CrossDC testsuite accesses Infinispan caches using ISPN's Rest API. This works well for some simple tasks, for example cache size but not for more difficult tasks.

For example, we are currently not able to list keys for client session cache because the cache uses UUID key type and the REST API do not have support for that. btw. it is also hard to list user session keys (we need to do some nasty magic to parse it from REST API response).

The solution to this is to use something that understands the cache structure for these calls. There are two options:

1. Using HotRod client (we would need to get KC Externalizers from KC codebase to CrossDC testsuite so this is probably too difficult)
2. Use Dataset provider functionality to access remote caches: https://github.com/keycloak/keycloak-benchmark/blob/main/dataset/src/main/java/org/keycloak/benchmark/cache/RemoteCacheResource.java

The second option is preferred as it is already implemented in dataset provider. The missing part is to implement https://github.com/keycloak/keycloak-benchmark/blob/main/provision/rosa-cross-dc/keycloak-benchmark-crossdc-tests/src/test/java/org/keycloak/benchmark/crossdc/client/InfinispanClient.java interface with calls to Dataset provider. As a nice to have would be to filter the sessions we are obtaining based on the realm as currently, we need to do another nasty magic to remove session ids created by Keycloak Admin Client from master realm.

The advantage of 1. would be we are not dependent on the dataset provider (which we are anyway with lb-check) and would be secured as the dataset provider is not secured at all.

[mhajas]

Revert b0a408a when this is resolved