[keycloak-user] Distributed Keycloak user sessions using Infinispan
Stian Thorgersen
stian at redhat.com
Wed Jul 29 13:20:43 EDT 2015
I'm away on holiday, Marek can you take a look at this?
----- Original Message -----
> From: "Rajat Nair" <rajat.nair at hp.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-user at lists.jboss.org
> Sent: Wednesday, 29 July, 2015 2:56:07 PM
> Subject: RE: [keycloak-user] Distributed Keycloak user sessions using Infinispan
>
> Follow up to our discussion -
>
> I upgrade my nodes to Keycloak 1.4 Final. Dropped and re-created database
> Postgres database (shared between both the nodes) and tested distributed
> user session using following commands -
> - Fetch access token using following curl from one server
> curl --write-out " %{http_code}" -s --request POST --header "Content-Type:
> application/x-www-form-urlencoded; charset=UTF-8" --data
> "username=user1 at email.com&password=testpassword@&client_id=admin-client&grant_type=password"
> "http://test-server-110:8080/auth/realms/test/protocol/openid-connect/token"
>
> - Validated the token on different server using
> curl --write-out " %{http_code}" -s --request GET --header "Content-Type:
> application/json" --header "Authorization: Bearer
> [ACCESS_TOKEN_FROM_PREVIOUS_CALL]"
> "http://test-server-111:8081/auth/realms/test/protocol/openid-connect/userinfo"
>
> And we get this - {"error":"invalid_grant","error_description":"Token
> invalid"}
> No more NPE and internal server error.
>
> If we use the same token and try to fetch user details on server which issued
> the token - we get the correct data. (Note - I have confirmed that the token
> has not expired)
>
> > One thing you can try is to make sure user session replication is working
> > properly:
> > 1. Start two nodes
> > 2. Open admin console directly on node 1 - login as admin/admin 3. Open
> > admin console directly on node 2 from another machine/browser or use
> > incognito mode - login as admin/admin 4. On node 1 go to users -> view all
> > -> click on admin -> sessions - > > you should see two sessions 5. On node
> > 2 do the same and check you can see two sessions there as well
> Now this is where things get strange. I followed the steps described - used 2
> different browsers - and I can see 2 sessions listed!
>
> Are the process we use to validate the token incorrect? Or is master console
> on the web doing something different (like get the data from Postgres
> database used by both the nodes).
>
> -- Rajat
>
> -----Original Message-----
> From: Stian Thorgersen [mailto:stian at redhat.com]
> Sent: 28 July 2015 10:19
> To: Nair, Rajat
> Cc: keycloak-user at lists.jboss.org
> Subject: Re: [keycloak-user] Distributed Keycloak user sessions using
> Infinispan
>
>
>
> ----- Original Message -----
> > From: "Rajat Nair" <rajat.nair at hp.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-user at lists.jboss.org
> > Sent: Monday, 27 July, 2015 7:33:25 PM
> > Subject: RE: [keycloak-user] Distributed Keycloak user sessions using
> > Infinispan
> >
> > > Can you send me your standalone-ha.xml and keycloak-server.json?
> > Files attached. The service is started like -
> > /opt/jboss/keycloak/bin/standalone.sh -c standalone-ha.xml
> > -b=test-server-110
> > -bmanagement=test-server-110 -u 230.0.0.4
> > -Djboss.node.name=test-server-110
> >
> > > Also, any chance you can try it out with master? I've been testing
> > > with that as we're about to do 1.4 release soon
> > Glad to give back to the community. Will build and deploy the master
> > on my nodes. Will send findings tomorrow.
> >
> > Regarding a scenario I described earlier - Case 2 1. Start with 1 Node
> > down. We bring it back up. We wait for some time so that Infinispan
> > can sync.
> > 2. Bring down other node.
> > 3. Try to get user info using existing token.
> >
> > Is this a valid use-case?
>
> Yes - I've tried the same use-case and it works fine every time. One caveat
> is that access token can expire, but in this case you should get a 403
> returned, not a NPE exception and 500.
>
> One thing you can try is to make sure user session replication is working
> properly:
>
> 1. Start two nodes
> 2. Open admin console directly on node 1 - login as admin/admin 3. Open admin
> console directly on node 2 from another machine/browser or use incognito
> mode - login as admin/admin 4. On node 1 go to users -> view all -> click on
> admin -> sessions - you should see two sessions 5. On node 2 do the same and
> check you can see two sessions there as well
>
> >
> > -- Rajat
> >
> > -----Original Message-----
> > From: Stian Thorgersen [mailto:stian at redhat.com]
> > Sent: 27 July 2015 19:16
> > To: Nair, Rajat
> > Cc: keycloak-user at lists.jboss.org
> > Subject: Re: [keycloak-user] Distributed Keycloak user sessions using
> > Infinispan
> >
> > Also, any chance you can try it out with master? I've been testing
> > with that as we're about to do 1.4 release soon
> >
> > ----- Original Message -----
> > > From: "Stian Thorgersen" <stian at redhat.com>
> > > To: "Rajat Nair" <rajat.nair at hp.com>
> > > Cc: keycloak-user at lists.jboss.org
> > > Sent: Monday, 27 July, 2015 3:45:46 PM
> > > Subject: Re: [keycloak-user] Distributed Keycloak user sessions
> > > using Infinispan
> > >
> > > Can you send me your standalone-ha.xml and keycloak-server.json?
> > >
> > > ----- Original Message -----
> > > > From: "Rajat Nair" <rajat.nair at hp.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: keycloak-user at lists.jboss.org
> > > > Sent: Monday, 27 July, 2015 3:41:36 PM
> > > > Subject: RE: [keycloak-user] Distributed Keycloak user sessions
> > > > using Infinispan
> > > >
> > > > > Do you have both nodes fully up and running before you kill one node?
> > > > Yes.
> > > > This is what we tried -
> > > > Case 1
> > > > 1. Two node cluster (both running Keycloak engines) - both up and
> > > > running.
> > > > Configured load balancing using mod_cluster.
> > > > 2. Login and get token.
> > > > 3. Bring down one node.
> > > > 4. Get user info using existing token. This is when we get NPE.
> > > >
> > > > Case 2
> > > > 1. Start with 1 Node down. We bring it back up. We wait for some
> > > > time so that Infinispan can sync.
> > > > 2. Bring down other node.
> > > > 3. Try to get user info using existing token. Again we see NPE.
> > > >
> > > > >It's a bug - if session is expired it should return an error
> > > > >message, not a NPE (see
> > > > >https://issues.jboss.org/browse/KEYCLOAK-1710)
> > > > Thanks for tracking this.
> > > >
> > > > -- Rajat
> > > >
> > > > ----- Original Message -----
> > > > > From: "Rajat Nair" <rajat.nair at hp.com>
> > > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > > Cc: keycloak-user at lists.jboss.org
> > > > > Sent: Monday, 27 July, 2015 3:20:27 PM
> > > > > Subject: RE: [keycloak-user] Distributed Keycloak user sessions
> > > > > using Infinispan
> > > > >
> > > > > Thanks for quick reply Stian.
> > > > >
> > > > > > What version?
> > > > > We are using Keycloak 1.3.1 Final.
> > > > >
> > > > > > Did you remember to change userSessions provider to infinispan
> > > > > > in keycloak-server.json?
> > > > > Yes. We got following in keycloak-server.json -
> > > > > "userSessions": {
> > > > > "provider": "infinispan"
> > > > > }
> > > > >
> > > > > > Firstly owners="2" should work fine as long as only one node
> > > > > > dies and the other remains active. Secondly it should return a
> > > > > > NPE, but an error if user session is not found.
> > > > > Could you elaborate on your 2nd point?
> > > >
> > > > Do you have both nodes fully up and running before you kill one node?
> > > >
> > > > It's a bug - if session is expired it should return an error
> > > > message, not a NPE (see
> > > > https://issues.jboss.org/browse/KEYCLOAK-1710)
> > > >
> > > > >
> > > > > -- Rajat
> > > > >
> > > > > -----Original Message-----
> > > > > From: Stian Thorgersen [mailto:stian at redhat.com]
> > > > > Sent: 27 July 2015 18:07
> > > > > To: Nair, Rajat
> > > > > Cc: keycloak-user at lists.jboss.org
> > > > > Subject: Re: [keycloak-user] Distributed Keycloak user sessions
> > > > > using Infinispan
> > > > >
> > > > > Did you remember to change userSessions provider to infinispan
> > > > > in keycloak-server.json?
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Stian Thorgersen" <stian at redhat.com>
> > > > > > To: "Rajat Nair" <rajat.nair at hp.com>
> > > > > > Cc: keycloak-user at lists.jboss.org
> > > > > > Sent: Monday, 27 July, 2015 2:24:17 PM
> > > > > > Subject: Re: [keycloak-user] Distributed Keycloak user
> > > > > > sessions using Infinispan
> > > > > >
> > > > > > What version?
> > > > > >
> > > > > > Firstly owners="2" should work fine as long as only one node
> > > > > > dies and the other remains active. Secondly it should return a
> > > > > > NPE, but an error if user session is not found.
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > > From: "Rajat Nair" <rajat.nair at hp.com>
> > > > > > > To: keycloak-user at lists.jboss.org
> > > > > > > Sent: Monday, 27 July, 2015 2:03:47 PM
> > > > > > > Subject: [keycloak-user] Distributed Keycloak user sessions
> > > > > > > using Infinispan
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I’m in the process of setting up distributed user sessions
> > > > > > > using Infinispan on my Keycloak cluster. This is the
> > > > > > > configuration I use –
> > > > > > >
> > > > > > > <cache-container name="keycloak"
> > > > > > > jndi-name="java:jboss/infinispan/Keycloak">
> > > > > > > lock-timeout="60000"/>
> > > > > > >
> > > > > > > <invalidation-cache name="realms" mode="SYNC"/>
> > > > > > >
> > > > > > > <invalidation-cache name="users" mode="SYNC"/>
> > > > > > >
> > > > > > > <distributed-cache name="sessions" mode="SYNC" owners="2"/>
> > > > > > >
> > > > > > > <distributed-cache name="loginFailures" mode="SYNC"
> > > > > > > owners="1"/>
> > > > > > >
> > > > > > > </cache-container>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > And in server.logs, I can see my servers communicate –
> > > > > > >
> > > > > > > 2015-07-27 10:27:24,662 INFO [org.infinispan.CLUSTER]
> > > > > > > (remote-thread--p3-t7)
> > > > > > > ISPN000310: Starting cluster-wide rebalance for cache users,
> > > > > > > topology CacheTopology{id=57, rebalanceId=17,
> > > > > > > currentCH=ReplicatedConsistentHash{ns
> > > > > > > =
> > > > > > > 60, owners = (1)[test-server-110: 60]},
> > > > > > > pendingCH=ReplicatedConsistentHash{ns = 60, owners =
> > > > > > > (2)[test-server-110:
> > > > > > > 30, test-server-111: 30]}, unionCH=null,
> > > > > > > actualMembers=[test-server-110, test-server-111]}
> > > > > > >
> > > > > > > 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER]
> > > > > > > (remote-thread--p3-t10)
> > > > > > > ISPN000310: Starting cluster-wide rebalance for cache
> > > > > > > realms, topology CacheTopology{id=57, rebalanceId=17,
> > > > > > > currentCH=ReplicatedConsistentHash{ns
> > > > > > > =
> > > > > > > 60, owners = (1)[test-server-110: 60]},
> > > > > > > pendingCH=ReplicatedConsistentHash{ns = 60, owners =
> > > > > > > (2)[test-server-110:
> > > > > > > 30, test-server-111: 30]}, unionCH=null,
> > > > > > > actualMembers=[test-server-110, test-server-111]}
> > > > > > >
> > > > > > > 2015-07-27 10:27:24,665 INFO [org.infinispan.CLUSTER]
> > > > > > > (remote-thread--p3-t8)
> > > > > > > ISPN000310: Starting cluster-wide rebalance for cache
> > > > > > > loginFailures, topology CacheTopology{id=57, rebalanceId=17,
> > > > > > > currentCH=DefaultConsistentHash{ns=80, owners =
> > > > > > > (1)[test-server-110:
> > > > > > > 80+0]},
> > > > > > > pendingCH=DefaultConsistentHash{ns=80, owners =
> > > > > > > (2)[test-server-110:
> > > > > > > 40+0,
> > > > > > > test-server-111: 40+0]}, unionCH=null,
> > > > > > > actualMembers=[test-server-110, test-server-111]}
> > > > > > >
> > > > > > > 2015-07-27 10:27:24,669 INFO [org.infinispan.CLUSTER]
> > > > > > > (remote-thread--p3-t9)
> > > > > > > ISPN000310: Starting cluster-wide rebalance for cache
> > > > > > > sessions, topology CacheTopology{id=56, rebalanceId=17,
> > > > > > > currentCH=DefaultConsistentHash{ns=80,
> > > > > > > owners = (1)[test-server-110: 80+0]},
> > > > > > > pendingCH=DefaultConsistentHash{ns=80,
> > > > > > > owners = (2)[test-server-110: 40+0, test-server-111: 40+0]},
> > > > > > > unionCH=null, actualMembers=[test-server-110,
> > > > > > > test-server-111]}
> > > > > > >
> > > > > > > 2015-07-27 10:27:24,808 INFO [org.infinispan.CLUSTER]
> > > > > > > (remote-thread--p3-t9)
> > > > > > > ISPN000336: Finished cluster-wide rebalance for cache
> > > > > > > loginFailures, topology id = 57
> > > > > > >
> > > > > > > 2015-07-27 10:27:24,810 INFO [org.infinispan.CLUSTER]
> > > > > > > (remote-thread--p3-t12)
> > > > > > > ISPN000336: Finished cluster-wide rebalance for cache
> > > > > > > sessions, topology id = 56
> > > > > > >
> > > > > > > 2015-07-27 10:27:24,988 INFO [org.infinispan.CLUSTER]
> > > > > > > (remote-thread--p3-t12)
> > > > > > > ISPN000336: Finished cluster-wide rebalance for cache
> > > > > > > realms, topology id =
> > > > > > > 57
> > > > > > >
> > > > > > > 2015-07-27 10:27:25,530 INFO [org.infinispan.CLUSTER]
> > > > > > > (remote-thread--p3-t8)
> > > > > > > ISPN000336: Finished cluster-wide rebalance for cache users,
> > > > > > > topology id =
> > > > > > > 57
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I can successfully login, get a token and fetch user details
> > > > > > > with this token.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Problem is, if one of the nodes on the cluster goes down and
> > > > > > > if we try to reuse a token which was already issued (so
> > > > > > > workflow is – user logins in, get token, (a node in the
> > > > > > > cluster goes down) and then fetch user details using
> > > > > > > token) – we see an internal server exception. From the logs
> > > > > > > –
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2015-07-27 10:24:25,714 ERROR [io.undertow.request] (default
> > > > > > > task-1)
> > > > > > > UT005023: Exception handling request to
> > > > > > > /auth/realms/scaletest/protocol/openid-connect/userinfo:
> > > > > > > java.lang.RuntimeException: request path:
> > > > > > > /auth/realms/scaletest/protocol/openid-connect/userinfo
> > > > > > >
> > > > > > > at
> > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter.d
> > > > > > > oF
> > > > > > > ilte
> > > > > > > r(
> > > > > > > KeycloakSessionServletFilter.java:54)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.
> > > > > > > java
> > > > > > > :6
> > > > > > > 0)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
> > > > > > > oF
> > > > > > > ilte
> > > > > > > r(
> > > > > > > FilterHandler.java:132)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.FilterHandler.handleRequest(Fil
> > > > > > > te
> > > > > > > rHan
> > > > > > > dl
> > > > > > > er.java:85)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.security.ServletSecurityRoleHan
> > > > > > > dl
> > > > > > > er.h
> > > > > > > an
> > > > > > > dleRequest(ServletSecurityRoleHandler.java:62)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.ServletDispatchingHandler.handl
> > > > > > > eR
> > > > > > > eque
> > > > > > > st
> > > > > > > (ServletDispatchingHandler.java:36)
> > > > > > >
> > > > > > > at
> > > > > > > org.wildfly.extension.undertow.security.SecurityContextAssoc
> > > > > > > ia
> > > > > > > tion
> > > > > > > Ha
> > > > > > > ndler.handleRequest(SecurityContextAssociationHandler.java:7
> > > > > > > 8)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest(P
> > > > > > > re
> > > > > > > dica
> > > > > > > te
> > > > > > > Handler.java:43)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.security.SSLInformationAssociat
> > > > > > > io
> > > > > > > nHan
> > > > > > > dl
> > > > > > > er.handleRequest(SSLInformationAssociationHandler.java:131)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.security.ServletAuthenticationC
> > > > > > > al
> > > > > > > lHan
> > > > > > > dl
> > > > > > > er.handleRequest(ServletAuthenticationCallHandler.java:57)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest(P
> > > > > > > re
> > > > > > > dica
> > > > > > > te
> > > > > > > Handler.java:43)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.security.handlers.AbstractConfidentialityHandler
> > > > > > > .h
> > > > > > > andl
> > > > > > > eR
> > > > > > > equest(AbstractConfidentialityHandler.java:46)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.security.ServletConfidentiality
> > > > > > > Co
> > > > > > > nstr
> > > > > > > ai
> > > > > > > ntHandler.handleRequest(ServletConfidentialityConstraintHand
> > > > > > > le
> > > > > > > r.ja
> > > > > > > va
> > > > > > > :64)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.security.handlers.AuthenticationMechanismsHandler.
> > > > > > > hand
> > > > > > > le
> > > > > > > Request(AuthenticationMechanismsHandler.java:58)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.security.CachedAuthenticatedSes
> > > > > > > si
> > > > > > > onHa
> > > > > > > nd
> > > > > > > ler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.security.handlers.NotificationReceiverHandler.ha
> > > > > > > nd
> > > > > > > leRe
> > > > > > > qu
> > > > > > > est(NotificationReceiverHandler.java:50)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.security.handlers.SecurityInitialHandler.handleR
> > > > > > > eq
> > > > > > > uest
> > > > > > > (S
> > > > > > > ecurityInitialHandler.java:76)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest(P
> > > > > > > re
> > > > > > > dica
> > > > > > > te
> > > > > > > Handler.java:43)
> > > > > > >
> > > > > > > at
> > > > > > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.
> > > > > > > ha
> > > > > > > ndleRequest(JACCContextIdHandler.java:61)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest(P
> > > > > > > re
> > > > > > > dica
> > > > > > > te
> > > > > > > Handler.java:43)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.server.handlers.PredicateHandler.handleRequest(P
> > > > > > > re
> > > > > > > dica
> > > > > > > te
> > > > > > > Handler.java:43)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.server.handlers.MetricsHandler.handleRequest(Met
> > > > > > > ri
> > > > > > > csHa
> > > > > > > nd
> > > > > > > ler.java:62)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.core.MetricsChainHandler.handleRequest(M
> > > > > > > et
> > > > > > > rics
> > > > > > > Ch
> > > > > > > ainHandler.java:59)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.handleFir
> > > > > > > st
> > > > > > > Requ
> > > > > > > es
> > > > > > > t(ServletInitialHandler.java:274)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchR
> > > > > > > eq
> > > > > > > uest
> > > > > > > (S
> > > > > > > ervletInitialHandler.java:253)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.ServletInitialHandler.access$00
> > > > > > > 0(
> > > > > > > Serv
> > > > > > > le
> > > > > > > tInitialHandler.java:80)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleR
> > > > > > > eq
> > > > > > > uest
> > > > > > > (S
> > > > > > > ervletInitialHandler.java:172)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.server.Connectors.executeRootHandler(Connectors.
> > > > > > > ja
> > > > > > > va:1
> > > > > > > 99
> > > > > > > )
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:
> > > > > > > 774)
> > > > > > >
> > > > > > > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> > > > > > > Source)
> > > > > > >
> > > > > > > at
> > > > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> > > > > > > Source)
> > > > > > >
> > > > > > > at java.lang.Thread.run(Unknown Source)
> > > > > > >
> > > > > > > Caused by: org.jboss.resteasy.spi.UnhandledException:
> > > > > > > java.lang.NullPointerException
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.ExceptionHandler.handleApplicationEx
> > > > > > > ce
> > > > > > > ptio
> > > > > > > n(
> > > > > > > ExceptionHandler.java:76)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.ExceptionHandler.handleException(Exc
> > > > > > > ep
> > > > > > > tion
> > > > > > > Ha
> > > > > > > ndler.java:212)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.writeException
> > > > > > > (S
> > > > > > > ynch
> > > > > > > ro
> > > > > > > nousDispatcher.java:149)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro
> > > > > > > no
> > > > > > > usDi
> > > > > > > sp
> > > > > > > atcher.java:372)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro
> > > > > > > no
> > > > > > > usDi
> > > > > > > sp
> > > > > > > atcher.java:179)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDi
> > > > > > > sp
> > > > > > > atch
> > > > > > > er
> > > > > > > .service(ServletContainerDispatcher.java:220)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
> > > > > > > he
> > > > > > > r.se
> > > > > > > rv
> > > > > > > ice(HttpServletDispatcher.java:56)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc
> > > > > > > he
> > > > > > > r.se
> > > > > > > rv
> > > > > > > ice(HttpServletDispatcher.java:51)
> > > > > > >
> > > > > > > at
> > > > > > > javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.ServletHandler.handleRequest(Se
> > > > > > > rv
> > > > > > > letH
> > > > > > > an
> > > > > > > dler.java:86)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
> > > > > > > oF
> > > > > > > ilte
> > > > > > > r(
> > > > > > > FilterHandler.java:130)
> > > > > > >
> > > > > > > at
> > > > > > > org.keycloak.services.filters.ClientConnectionFilter.doFilte
> > > > > > > r(
> > > > > > > Clie
> > > > > > > nt
> > > > > > > ConnectionFilter.java:41)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.
> > > > > > > java
> > > > > > > :6
> > > > > > > 0)
> > > > > > >
> > > > > > > at
> > > > > > > io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.d
> > > > > > > oF
> > > > > > > ilte
> > > > > > > r(
> > > > > > > FilterHandler.java:132)
> > > > > > >
> > > > > > > at
> > > > > > > org.keycloak.services.filters.KeycloakSessionServletFilter.d
> > > > > > > oF
> > > > > > > ilte
> > > > > > > r(
> > > > > > > KeycloakSessionServletFilter.java:40)
> > > > > > >
> > > > > > > ... 31 more
> > > > > > >
> > > > > > > Caused by: java.lang.NullPointerException
> > > > > > >
> > > > > > > at
> > > > > > > org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issueU
> > > > > > > se
> > > > > > > rInf
> > > > > > > o(
> > > > > > > UserInfoEndpoint.java:128)
> > > > > > >
> > > > > > > at
> > > > > > > org.keycloak.protocol.oidc.endpoints.UserInfoEndpoint.issueU
> > > > > > > se
> > > > > > > rInf
> > > > > > > oG
> > > > > > > et(UserInfoEndpoint.java:101)
> > > > > > >
> > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > > > > > > Method)
> > > > > > >
> > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown
> > > > > > > Source)
> > > > > > >
> > > > > > > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> > > > > > > Source)
> > > > > > >
> > > > > > > at java.lang.reflect.Method.invoke(Unknown Source)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje
> > > > > > > ct
> > > > > > > orIm
> > > > > > > pl
> > > > > > > .java:137)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget
> > > > > > > (R
> > > > > > > esou
> > > > > > > rc
> > > > > > > eMethodInvoker.java:296)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc
> > > > > > > eM
> > > > > > > etho
> > > > > > > dI
> > > > > > > nvoker.java:250)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTarge
> > > > > > > tO
> > > > > > > bjec
> > > > > > > t(
> > > > > > > ResourceLocatorInvoker.java:140)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Resour
> > > > > > > ce
> > > > > > > Loca
> > > > > > > to
> > > > > > > rInvoker.java:109)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTarge
> > > > > > > tO
> > > > > > > bjec
> > > > > > > t(
> > > > > > > ResourceLocatorInvoker.java:135)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(Resour
> > > > > > > ce
> > > > > > > Loca
> > > > > > > to
> > > > > > > rInvoker.java:103)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro
> > > > > > > no
> > > > > > > usDi
> > > > > > > sp
> > > > > > > atcher.java:356)
> > > > > > >
> > > > > > > ... 42 more
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > The user guide says –
> > > > > > >
> > > > > > > If you need to prevent node failures from requiring users to
> > > > > > > log in again, set the owners attribute to 2 or more for the
> > > > > > > sessions cache
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Questions -
> > > > > > >
> > > > > > > 1. Have we configured Infinispan incorrectly? We don’t want
> > > > > > > the users to login again if any of the nodes in the cluster
> > > > > > > go down.
> > > > > > >
> > > > > > > 2. Will changing distributed-cache to replicated-cache help
> > > > > > > in this scenario?
> > > > > > >
> > > > > > > 3. Any way we can see the contents of the cache?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -- Rajat
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > keycloak-user mailing list
> > > > > > > keycloak-user at lists.jboss.org
> > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > > >
> > > > > > _______________________________________________
> > > > > > keycloak-user mailing list
> > > > > > keycloak-user at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > >
> > > >
> > >
> >
>
More information about the keycloak-user
mailing list