0

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)
Fagner Brack
  • 2,365
  • 4
  • 33
  • 69

1 Answers1

1

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.

Fagner Brack
  • 2,365
  • 4
  • 33
  • 69
redge
  • 1,182
  • 7
  • 6
  • Alright but then the same code would fail for JBoss EAP 6.1 right? The thing is... it doesn't! I will post the whole stacktrace in a gist (it's pretty big), then I update the answer. – Fagner Brack Apr 25 '15 at 02:45
  • You added this may have changed the behavior. Was your 6.1 deployment clustered and replicating properly? – redge Apr 25 '15 at 03:04
  • I didn't added ``. It already was in the code base working with JBoss EAP 6.1. – Fagner Brack Apr 25 '15 at 03:04
  • Can you include the full stacktrace including any nested exceptions? – redge Apr 25 '15 at 04:15
  • I am sorry, I couldn't reproduce anymore. I believe my analysis was biased due to a missing property file that caused a runtime error. I assumed to be a server problem without inspecting the full log properly (lazy, lazy boy). Now I can't get back to the point where it was reproducible. The correct answer in this case would be to explain why this usually occurs. For example: JBoss fails to read the session if there is another runtime error shown in the full stacktrace, most of the time this is not a server problem but an application problem, like a mising property file. Thanks – Fagner Brack Apr 25 '15 at 13:39
  • (I couldn't add the stacktrace earlier because I had some external issues) – Fagner Brack Apr 25 '15 at 13:40