Repository navigation
Session expires immediatly with remote infinispan cluster and JDBC persistence #10577
Replies: 2 comments 6 replies
|
Hi, litlle up, in case someone has ever tried ISPN JDBC persistence ... thanks |
|
@daviddelannoy thansk for the useful reproducer! I also tested this with a custom docker-image from the latest main branch (18.0.0-SNAPSHOT) and there I see the same problem. I think the problem is here: https://github.com/keycloak/keycloak/blob/main/model/infinispan/src/main/java/org/keycloak/models/sessions/infinispan/remotestore/RemoteCacheInvoker.java#L132 case REPLACE:
replace(topology, remoteCache, task.getLifespanMs(), maxIdleMs, key, task);
break;
I just gave this a spin - the following PoC (Patch included) works for me: I don't know yet whether this would be a proper fix but other folks like @mposolda know the infinispan internals better :) |
|
Should I reference this discussion in a new issue ? Thanks |
|
@daviddelannoy sure :) |
|
We also have this requirement: "user sessions must be persisted in database". We migrated from Keycloak 10.0.2 to KeycloakX 17.0.0 but it still it is unclear for us how to achieve it. Ideally we would like to use direct jdbc-store on keycloak embeded ISPN distributed-caches (session, clientSessions). Thanks |
|
@daviddelannoy I jsut gave this another spin and tested this with Keycloak 17.0.1 case REPLACE:
// BEGIN-PATCH
long lifespanPatch = Time.currentTimeMillis() + task.getLifespanMs();
long maxIdlePatch = Time.currentTimeMillis() + maxIdleMs;
replace(topology, remoteCache, lifespanPatch, maxIdlePatch, key, task);
// replace(topology, remoteCache, -1, maxIdleMs, key, task);
// END-PATCH |
|
Yes thanks, it seems to be OK like that. I created an issue from this discussion but I think it is still in triage : 10755 Just like @sstepien in message above, in the meantime we tested direct JDBC store but faced another problem on which you also have proposed a patch (see 10803 (thanks for that ). So right now, two options are available to us, the two of them require their own patch and documentation is not very clear about what should be the recommended one, especially with Quarkus (except the : do not persist user and client sessions ^^) Any input on this subject will help us (and others) to choose the most reliable solution |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi,
We are facing a strange bug with a remote Infinispan cluster with JDBC persistence and Keycloak (wildfly based).
I agree that it is quite an unusual set-up but we have to make it work...
Keycloak 17.0.0 (legacy, wildfly) (will be migrated to Quarkus in a few months)
Infinispan 13.0.6.Final
PostgreSQL 14.X
Note : this bug does not occur with a remote Infinispan cluster without JDBC persistence.
Scenario :
https://github.com/olivierboudet/keycloak-infinispan-jdbc
docker-compose up
We have looked at theses classes and put them in DEBUG but were not able to identify the root cause :
org.keycloak.models.sessions.infinispan.remotestore.RemoteCacheSessionListener
org.keycloak.models.sessions.infinispan.remotestore.RemoteCacheInvoker
org.keycloak.models.sessions.infinispan.InfinispanUserSessionProvider
If anyone can help us on this problem ...
Is there a big mistake in our configuration ? we simplified it a bit for the example (remove security, single Keycloak/ISPN instance, ...)
thanks
All reactions