Cross-site validation for lazy loading of offline sessions & Switch d…#9414
Cross-site validation for lazy loading of offline sessions & Switch d…#9414hmlnarik merged 1 commit intokeycloak:mainfrom
Conversation
a4a4478 to
b244987
Compare
9c00184 to
4eb70f7
Compare
|
Documentation + release notes PR keycloak/keycloak-documentation#1362 |
|
Pipeline run: |
|
Link to GH discussion |
mhajas
left a comment
There was a problem hiding this comment.
Thank you for the PR @martin-kanis! I added few comments/questions
6b64cd5 to
1c01acf
Compare
mhajas
left a comment
There was a problem hiding this comment.
Thank you for the changes @martin-kanis. This looks good to me, I added one more idea though. Feel free to scratch it if you don't think it makes sense or it isn't possible. I am approving as it works this way too.
There was a problem hiding this comment.
One more idea to this, I am not sure this could work this way, but I believe it is worth trying since it could have better performance.
| @NamedQuery(name="findClientSessionsClientIds", query="SELECT clientSess.clientId, clientSess.externalClientId, clientSess.clientStorageProvider" + | |
| " FROM PersistentClientSessionEntity clientSess INNER JOIN PersistentUserSessionEntity sess ON clientSess.userSessionId = sess.userSessionId " + | |
| " WHERE sess.offline = :offline AND sess.realmId = :realmId") | |
| @NamedQuery(name="findClientSessionsClientIds", query="SELECT clientSess.clientId, clientSess.externalClientId, clientSess.clientStorageProvider, count(clientSess)" + | |
| " FROM PersistentClientSessionEntity clientSess INNER JOIN PersistentUserSessionEntity sess ON clientSess.userSessionId = sess.userSessionId " + | |
| " WHERE sess.offline = :offline AND sess.realmId = :realmId" + | |
| "GROUP BY clientSess.clientId, clientSess.externalClientId, clientSess.clientStorageProvider") |
This way we could get rid of this:
closing(query.getResultStream())
.map(row -> {
String clientId = row[0].toString();
if (clientId.equals(PersistentClientSessionEntity.EXTERNAL)) {
final String externalClientId = row[1].toString();
final String clientStorageProvider = row[2].toString();
clientId = new StorageId(clientStorageProvider, externalClientId).getId();
}
return clientId;
})
.sorted()
.collect(Collectors.groupingBy(Function.identity(), Collectors.counting()));
and replace it with something like this:
closing(query.getResultStream())
.collect(Collectors.toMap(row -> {
String clientId = row[0].toString();
if (clientId.equals(PersistentClientSessionEntity.EXTERNAL)) {
final String externalClientId = row[1].toString();
final String clientStorageProvider = row[2].toString();
clientId = new StorageId(clientStorageProvider, externalClientId).getId();
}
return clientId;
}, row -> (Long) row[3])); // Not sure about the exact type of row[3] so I am not sure this will work
WDYT?
There was a problem hiding this comment.
I think it might work. I'll double check it with some tests. But what about ordering? Do we care about order of the entries in the resulting map by final clientId? If yes, we probably need ordering in Java.
There was a problem hiding this comment.
Hmm, this is a good question, I completely missed it. The previous method used HashMap for returning the result and HashMap does not preserve order so I believe the order is not needed. Also, the current order would be a little bit different as we are using StorageId that is producing id in the form f:......:....... which wasn't there before. Maybe we could get another opinion on this, whether some order is needed @hmlnarik? WDYT?
In case some order is needed, I believe it would be possible to use something like that: ORDER BY clientSess.clientId, clientSess.clientStorageProvider.
There was a problem hiding this comment.
Yeah, we probably don't have to care about ordering as the return type is HashMap. The method is called only from AdminRealmResource where the map is again transformed and return type is Stream<Map<String, String>>.
I also extended one test in ClientStorageTest to test the query more.
68a6b7e to
83150a8
Compare
…efault offline sessions to lazy loaded
|
https://master-jenkins.com/job/universal-test-pipeline-server/1187 The adapter failure is suspicious: But it can be also found in an older run https://master-jenkins.com/job/universal-test-pipeline-adapters/857/execution/node/932/log/?consoleFull so it's probably not a regression. |
hmlnarik
left a comment
There was a problem hiding this comment.
Well done, @martin-kanis !
…efault offline sessions to lazy loaded
This PR add test scenarios to model testsuite which will test offline sessions lazy loading (in Cross DC environment) and make offline sessions to be lazy loaded by default.
Closes #9409
Closes #9410