Are you sure your classes are Serializable?
Which version of JBoss?
What is your jboss-web.xml clustering configuration, if any?
Thanks for the reply.
I am quite certain the classes are serializable. For a while, we had one that was not, but it was made quite evident by errors in the log, which we are no longer getting.
I have een observing this issue in 3.2.3, so I wrote a proof of concept (with only String values in the session) which also did not work until I upgraded to 3.2.4RC1, based on the "UseLocalCache attribute set to false" recommendation I read elsewhere, so 3.2.4RC1 ran the proof of concept fine, but not my full app.
I have used both the following in my testing of the full app:
<?xml version="1.0" encoding="UTF-8"?> <jboss-web> <context-root>/</context-root> <replication-config> <replication-trigger>SET</replication-trigger> <replication-type>SYNC</replication-type> </replication-config> </jboss-web>
<?xml version="1.0" encoding="UTF-8"?> <jboss-web> <replication-config> <replication-trigger>SET_AND_GET</replication-trigger> <replication-type>SYNC</replication-type> </replication-config> </jboss-web>
Have you configured "sticky" sesssions for your HTTP load balancer?
do you have a sample WAR archive I could use? I can then simply drop it in two clustered JBoss instances and see how it behaves for me with default JBoss binaries.
Yes, the load balancer is a Cisco CSS configured for sticky least conns.
Re: WAR Archive
The current full war has a whole legacy system dependency, but I will contrive a duplucation of the problem and send it.
I am still working on reproducing a WAR I can send you. (Which will probably result in me banging my head with my fist when I realize what the problem is....)
However, I am still inclined toward the possibility that there is some sort of class loading issue going on in the replication layer. Based on this assumption, I introduced a servlet filter that converts all the session attributes to byte arrays and then back to objects. Again, this was done a bit roughly, so it does make the app break, but I found that the non java.lang based objects did replicate when converted to byte arrays. I also found that the object sizes reach as large as 46K.
What I am not seeing is any error messages at all.
I finally resolved this. Basically, I made the classes that were being written to the HTTPSession externalizable. This has the double benefit of loudly complaining when something does not serialize properly, and it reduces the payload size by 40 to 1.
The last issue is (I am fairly sure) related to bug #863113. Since this patch post-dated the 3.2.3 release, I can either
1.Wait for 3.2.4
2.Rebuild 3.2.3 from CVS
3.Roll with 3.2.4RC1
Any idea on the time line for 3.2.4 ?