Nearly There With HTTPSession Repl: One More Issue (Class Vi

[nickman]

After trying several different configurations, and a sample app that worked when the HttpSession contained only java.lang.Strings, I realized that the my app is not replicationg sessions across the cluster when it contains application specific classes, as oposed to java.lang.* classes. When I contrive a session to use Strings only, it works like a champ.

The classes are loaded in WAR file, which in turn is in an EAR file, so I believe this may be a class visibility issue, where the clustered session and distributed state layer may not have access to the class type of the objects being bound into the session. However, I have run the app with org.jboss.web.tomcat.tc5.session and org.jboss.ha at TRACE logging and I am not seeing any errors.

Has anyone seen this behaviour ?
Any ideas ?

Thanks.

//Nicholas

[slaboure]

Are you sure your classes are Serializable?

Which version of JBoss?

What is your jboss-web.xml clustering configuration, if any?

sacha

[nickman]

Sacha;

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>

and

<?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>

Thanks again.

//Nicholas

[juha]

Have you configured "sticky" sesssions for your HTTP load balancer?

[slaboure]

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.

sacha

[nickman]

Yes, the load balancer is a Cisco CSS configured for sticky least conns.

[nickman]

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.

Thanks.

//Nicholas

[nickman]

Sacha;

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.

Cheers.

//Nicholas

[nickman]

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 ?

Thanks.

//Nicholas