Search code examples
javajbossweb.xmljboss-eap-6session-replication

Why JBoss EAP 6.4 fail to load the session using the http session replication mechanism?


I have been using session replication successfully in JBoss EAP 6.1 in Windows. But then I changed to JBoss EAP 6.4 for dev testing in ubuntu and the same code stopped working.

There's not much to it, I just added the <distributable/> tag and didn't added any manual serialVersionUID value to the serialized class Logged.java (it stays annotated to ignore the warnings).

I store the instance of the class in the http session, shutdown the server using jboss-cli.sh --connect command=:shutdown (NOPAUSE=true environment variable), then startup the server again. After server is started, when I try to access the session again I cannot retrieve the class instance and the following error occurs in the console:

...

21:47:13,852 WARN  [org.jboss.as.clustering.web.infinispan] (http-/0.0.0.0:80-1)
 JBAS010322: Failed to load session 9OQtRW3Vgc-uf8w3DmRHD+PK: java.lang.RuntimeE
xception: JBAS010333: Failed to load session attributes for session: 9OQtRW3Vgc-
uf8w3DmRHD+PK
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$2.invo
ke(DistributedCacheManager.java:229)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$2.invoke(DistributedCacheManager.java:212)
        at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
        at org.jboss.as.clustering.infinispan.invoker.BatchCacheInvoker.invoke(BatchCacheInvoker.java:48)
        at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:85)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager$ForceSynchronousCacheInvoker.invoke(DistributedCacheManager.java:550)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getData(DistributedCacheManager.java:238)
        at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.getSessionData(DistributedCacheManager.java:196)
        at org.jboss.as.web.session.DistributableSessionManager.loadSession(DistributableSessionManager.java:1429) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
        at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:688) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
 at org.jboss.as.web.session.DistributableSessionManager.findSession(DistributableSessionManager.java:84) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
        at org.apache.catalina.connector.Request.doGetSession(Request.java:2661) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
        at org.apache.catalina.connector.Request.getSession(Request.java:2382) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
        at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:791) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
        at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:801) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
        at org.webstories.core.auth.AuthSession.from(AuthSession.java:12) [classes:]
...

I have no idea where to start looking into because I have no knowledge of JBoss internals, except for what is widely documented throughout the web. In this case what is documented is that you just need to add <distributable/> into the web.xml and then session replication will "magically" start working. Of course, you need to declare a class instance as serializable to be able to be serialized, but besides that I see no reason for why it is not working in JBoss EAP 6.4 in Ubuntu.

lsb_release -a:

No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:        14.04
Codename:       trusty

java -version:

java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) Client VM (build 25.45-b02, mixed mode)

Solution

  • Follow the stack trace down. There should be a cause (nested exception) and I suspect that it is a not serializable or a null pointer. Otherwise you may be able to find another exception earlier that is a not-serializable

    The most likely cause of session persistence/replication issues is trying to store a non-serializable object in the session. This causes the storage of the session to fail and the subsequent retrieval cannot proceed.

    Remember that not only the class being stored must be serializable but any non-static non-transient fields recursively. This can be very difficult and tedious to find.

    With regard to the serialVersionUID this will only cause issues if you have versions from different compiles deployed in different servers within the cluster as the compiler will create one automatically so if they are from the same compile they will match.