[keycloak-user] Lost session when removing an instance off cluster

[Stian Thorgersen]

Can you please include more details from the log if there is any, at least
a full stack trace and not just the bit you've included. We also need to
know details around how you've configured the caches and Infinispan.

On 1 July 2016 at 10:16, Sarp Kaya <akaya at expedia.com> wrote:

> Hello,
>
> I have tried various ways of configuring infinispan but it just seems like
> if I deploy a new instance to the cluster and remove one, then some
> sessions are lost and an exception is thrown saying that it was not
> handled. This is the Infinispan exception:
>
> Exception handling request to /auth/realms/realmname/protocol/openid-
> connect/auth: org.jboss.resteasy.spi.UnhandledException: org.infinispan.
> util.concurrent.TimeoutException: Replication timeout for 79a0757ecab3 at
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.
> java:247) at org.jboss.resteasy.core.SynchronousDispatcher.writeException(
> SynchronousDispatcher.java:168) at org.jboss.resteasy.core.
> SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:471) at org
> .jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.
> java:415) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(
> SynchronousDispatcher.java:202) at org.jboss.resteasy.plugins.server.
> servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java
> :221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.
> service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.
> server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at io.
> undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java
> :85) at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.
> doFilter(FilterHandler.java:129) at org.keycloak.services.filters.
> KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:88)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(
> FilterHandler.java:131) at io.undertow.servlet.handlers.FilterHandler.
> handleRequest(FilterHandler.java:84) at io.undertow.servlet.handlers.
> security.ServletSecurityRoleHandler.handleRequest(
> ServletSecurityRoleHandler.java:62) at io.undertow.servlet.handlers.
> ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.
> SecurityContextAssociationHandler.handleRequest(
> SecurityContextAssociationHandler.java:78) at io.undertow.server.handlers.
> PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.
> servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(
> SSLInformationAssociationHandler.java:131) at io.undertow.servlet.handlers
> .security.ServletAuthenticationCallHandler.handleRequest(
> ServletAuthenticationCallHandler.java:57) at io.undertow.server.handlers.
> PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.
> security.handlers.AbstractConfidentialityHandler.handleRequest(
> AbstractConfidentialityHandler.java:46) at io.undertow.servlet.handlers.
> security.ServletConfidentialityConstraintHandler.handleRequest(
> ServletConfidentialityConstraintHandler.java:64) at io.undertow.security.
> handlers.AuthenticationMechanismsHandler.handleRequest(
> AuthenticationMechanismsHandler.java:60) at io.undertow.servlet.handlers.
> security.CachedAuthenticatedSessionHandler.handleRequest(
> CachedAuthenticatedSessionHandler.java:77) at io.undertow.security.
> handlers.NotificationReceiverHandler.handleRequest(
> NotificationReceiverHandler.java:50) at io.undertow.security.handlers.
> AbstractSecurityContextAssociationHandler.handleRequest(
> AbstractSecurityContextAssociationHandler.java:43) at io.undertow.server.
> handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) at org.
> wildfly.extension.undertow.security.jacc.JACCContextIdHandler.
> handleRequest(JACCContextIdHandler.java:61) at io.undertow.server.handlers
> .PredicateHandler.handleRequest(PredicateHandler.java:43) at io.undertow.
> server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(
> ServletInitialHandler.java:284) at io.undertow.servlet.handlers.
> ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263) at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(
> ServletInitialHandler.java:81) at io.undertow.servlet.handlers.
> ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174) at
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) at
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
> java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.util.concurrent.TimeoutException: Replication
> timeout for 79a0757ecab3 at org.infinispan.remoting.transport.jgroups.
> JGroupsTransport.checkRsp(JGroupsTransport.java:765) at org.infinispan.
> remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$72(
> JGroupsTransport.java:599) at java.util.concurrent.CompletableFuture.
> uniApply(CompletableFuture.java:602) at java.util.concurrent.
> CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) at java.
> util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:
> 1962) at org.infinispan.remoting.transport.jgroups.SingleResponseFuture.
> call(SingleResponseFuture.java:46) at org.infinispan.remoting.transport.
> jgroups.SingleResponseFuture.call(SingleResponseFuture.java:17) at java.
> util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.
> concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(
> ScheduledThreadPoolExecutor.java:180)
>
> This causes browsers to see Internal Server Error. Shouldn’t that be
> handled in Keycloak as lost session, therefore KC should try to handle it
> rather than showing that it’s an Internal Server Error?
>
> My current infinispan configuration looks like this:
>
> <distributed-cache name="sessions" mode="SYNC">
>     <transaction mode="NON_DURABLE_XA"/>
> </distributed-cache>
>
>
> I use Keycloak version 1.9.5. My question is am I doing something wrong
> with my configuration? I tried both replicated-cache and distributed-cache
> and tried all transaction mode on both of them. None of them seems to solve
> the error that I’ve had above.
>
> Kind Regards,
> Sarp Kaya
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160701/4a22c315/attachment-0001.html