The cache replace logic depends on it, as values returned by reference from a local cache must never be modified on those critical fields directly.
Closes#28906
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
Closes#28303
Signed-off-by: Pedro Ruivo <pruivo@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
* Execute persistent sessions tests in CI and fix deadlock in UserSessionConcurrencyTest
The deadlock was caused by a switch to reactive handling of embedded Infinispan updates introduced here #28862Closes#29235
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
All writes for the sessions are handled by a background thread which batches them.
Closes#28862
Wait for persistent-store to contain update
instead of cache which has the change immediately since it is in memory + introduce new model-test profile
Closes#29141
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
Defer updates of last session refreshes and batch them
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
+ since the runSerialized mechanism is currently on the best effort basis it is possible there are concurrent executions if T1 obtained a lock T2 removed the lock and T3 created a new lock before T1 called putIfAbsent therefore I added a debug log detecting this situation
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Signed-off-by: vibrown <vibrown@redhat.com>
More updates
Signed-off-by: vibrown <vibrown@redhat.com>
Added client type logic from Marek's prototype
Signed-off-by: vibrown <vibrown@redhat.com>
updates
Signed-off-by: vibrown <vibrown@redhat.com>
updates
Signed-off-by: vibrown <vibrown@redhat.com>
updates
Signed-off-by: vibrown <vibrown@redhat.com>
Testing to see if skipRestart was cause of test failures in MR
Adding two feature toggles for new code paths to store online sessions in the existing offline sessions table. Separate the code which is due to be changed in the next iteration in new classes/providers which used instead of the old one.
Closes#27976
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
Closes#25676
Signed-off-by: vramik <vramik@redhat.com>
Signed-off-by: Pedro Ruivo <pruivo@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Pedro Ruivo <pruivo@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
Closes#26941
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
Closes#26810
Co-authored-by: Thomas Darimont <thomas.darimont@googlemail.com>
Co-authored-by: Martin Kanis <mkanis@redhat.com>
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
Signed-off-by: Martin Kanis <mkanis@redhat.com>
This PR introduces a String getTaskName() default method to
the ScheduledTask interface and adjusts call sites to use the
implementation derived task name where possible.
Previously, ScheduledTask names were passed around separately, which
lead to unhelpful debug messages.
We now give ScheduledTask implementations control over their task-name
which allows for more flexible naming.
Enlist call StoreSyncEvent.fire(...) to after transaction to ensure realm is present in database.
Ensure that Realm is already committed before updating sync via UserStorageSyncManager
Align Sync task name generation for cancellation to support SyncFederationTest
Only log a message if sync task was actually canceled.
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
Closes#26460
Signed-off-by: Václav Muzikář <vmuzikar@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
Closes#22922
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Pedro Ruivo <pruivo@redhat.com>
Co-authored-by: Pedro Ruivo <pruivo@redhat.com>
Closes#25077
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Pedro Ruivo <pruivo@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
closes#22372
Co-authored-by: Erik Jan de Wit <erikjan.dewit@gmail.com>
Co-authored-by: Pedro Igor <pigor.craveiro@gmail.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
The problem is again the wrap(...) function.
In case the user is not found, then null is
returned. This can happen when a federated user
is deleted on the federation side but Keycloak
is not informed about it. In that case, the
session is still present but no UserModel can
be created.
Without this patch the stream contains null
values. Some downstream users can not cope well
with that.
The adjustment of the function getUserSessionsCount(...)
is slightly more expensive in execution, but
returns the correct number.
Closes#22428
Co-authored-by: Martin Krüger <mkrueger@mkru.de>
* Review comments to add a test, update the API description and adjust the map storage.
Closes#19348
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
* keycloak-20847 Find an appropriate key based on the given KID and JWA. Prefers matching on both inputs but will match on partials if found. Or return the first key if a match is not found.
Mark Key as fallback if it is the singular client certificate to be used for signed JWT authentication.
* Update js/apps/admin-ui/public/locales/en/clients.json
Co-authored-by: Marek Posolda <mposolda@gmail.com>
* Updating boolean variable name based on suggestions by Marek.
* Adding integration test specifically for the JWT parameters for regression #20847.
---------
Co-authored-by: Marek Posolda <mposolda@gmail.com>
With Hibernate ORM 6, pagination started to be unreliable: When
setting the max results only if the first row was 0 has randomly
affected other threads where first row was greater than 0. The
latter thread sometimes produced query which did *not* account
for the offset (cf. threads `-t1` and `-t2` below, while `-t2`
missed the `offset ? rows` part whic `-t3` has).
This has been fixed by setting the first row offset unconditionally.
Closes: #20202Closes: #16570
```
2023-06-02 10:19:03.855000 TRACE [org.keycloak.models.sessions.infinispan.initializer.SessionInitializerWorker] (blocking-thread-node-2-p8-t1) Running computation for segment 0 with worker 0
2023-06-02 10:19:03.856000 TRACE [org.keycloak.models.sessions.infinispan.initializer.OfflinePersistentUserSessionLoader] (blocking-thread-node-2-p8-t1) Loading sessions for segment=0 lastSessionId=00000000-0000-0000-0000-000000000000 first=0
2023-06-02 10:19:03.856000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t1) Set max to 64 in org.hibernate.query.sqm.internal.QuerySqmImpl@2fb60f8b
2023-06-02 10:19:03.856000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t1) After pagination: 0, 64
2023-06-02 10:19:03.857000 TRACE [org.keycloak.models.sessions.infinispan.initializer.SessionInitializerWorker] (blocking-thread-node-2-p8-t2) Running computation for segment 1 with worker 1
2023-06-02 10:19:03.857000 TRACE [org.keycloak.models.sessions.infinispan.initializer.OfflinePersistentUserSessionLoader] (blocking-thread-node-2-p8-t2) Loading sessions for segment=1 lastSessionId=00000000-0000-0000-0000-000000000000 first=64
2023-06-02 10:19:03.857000 TRACE [org.keycloak.models.sessions.infinispan.initializer.SessionInitializerWorker] (blocking-thread-node-2-p8-t3) Running computation for segment 2 with worker 2
2023-06-02 10:19:03.857000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t2) Set first to 64 in org.hibernate.query.sqm.internal.QuerySqmImpl@71464e9f
2023-06-02 10:19:03.857000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t2) Set max to 64 in org.hibernate.query.sqm.internal.QuerySqmImpl@71464e9f
2023-06-02 10:19:03.857000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t2) After pagination: 64, 64
2023-06-02 10:19:03.857000 TRACE [org.keycloak.models.sessions.infinispan.initializer.OfflinePersistentUserSessionLoader] (blocking-thread-node-2-p8-t3) Loading sessions for segment=2 lastSessionId=00000000-0000-0000-0000-000000000000 first=128
10:19:03,859 DEBUG [org.hibernate.SQL] (blocking-thread-node-2-p8-t1)
select
p1_0.OFFLINE_FLAG,
p1_0.USER_SESSION_ID,
p1_0.CREATED_ON,
p1_0.DATA,
p1_0.LAST_SESSION_REFRESH,
p1_0.REALM_ID,
p1_0.USER_ID
from
OFFLINE_USER_SESSION p1_0,
REALM r1_0
where
r1_0.ID=p1_0.REALM_ID
and p1_0.OFFLINE_FLAG=?
and p1_0.USER_SESSION_ID>?
order by
p1_0.USER_SESSION_ID fetch first ? rows only
10:19:03,859 DEBUG [org.hibernate.SQL] (blocking-thread-node-2-p8-t2)
select
p1_0.OFFLINE_FLAG,
p1_0.USER_SESSION_ID,
p1_0.CREATED_ON,
p1_0.DATA,
p1_0.LAST_SESSION_REFRESH,
p1_0.REALM_ID,
p1_0.USER_ID
from
OFFLINE_USER_SESSION p1_0,
REALM r1_0
where
r1_0.ID=p1_0.REALM_ID
and p1_0.OFFLINE_FLAG=?
and p1_0.USER_SESSION_ID>?
order by
p1_0.USER_SESSION_ID fetch first ? rows only
2023-06-02 10:19:03.860000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t1) binding parameter [1] as [VARCHAR] - [1]
2023-06-02 10:19:03.860000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t1) binding parameter [2] as [VARCHAR] - [00000000-0000-0000-0000-000000000000]
2023-06-02 10:19:03.860000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t1) binding parameter [3] as [INTEGER] - [64]
10:19:03,860 DEBUG [org.hibernate.SQL] (blocking-thread-node-2-p8-t3)
select
p1_0.OFFLINE_FLAG,
p1_0.USER_SESSION_ID,
p1_0.CREATED_ON,
p1_0.DATA,
p1_0.LAST_SESSION_REFRESH,
p1_0.REALM_ID,
p1_0.USER_ID
from
OFFLINE_USER_SESSION p1_0,
REALM r1_0
where
r1_0.ID=p1_0.REALM_ID
and p1_0.OFFLINE_FLAG=?
and p1_0.USER_SESSION_ID>?
order by
p1_0.USER_SESSION_ID offset ? rows fetch first ? rows only
2023-06-02 10:19:03.861000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t3) binding parameter [3] as [INTEGER] - [128]
2023-06-02 10:19:03.861000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t3) binding parameter [4] as [INTEGER] - [64]
```
Co-authored-by: mkanis <mkanis@redhat.com>
