Using JBossSerialization with HttpSession Replication (JBAS-

[hmesha]

Hi all,
discussion for JBAS-2921

Currenlty, Http Session replication employ JavaSerialization to perfrom object serialization before inserting sessions or attributes in the cache. What we would like to do is provide an additional option to use JBossSerialization. The problem there's no server wide configuration property to toggle between JavaSerialization and JBossSerialization.

Here's the solution that I'm proposing

1. provide a configurable property in jboss-web.xml. Possible values are:
<session-serialization>JBossSerialization</session-serialization>
or
<session-serialization>JavaSerialization</session-serialization> (default value)

or
<NOT EXIST> (default to JavaSerialization)

2. add dependency on JBossRemoting to take advantage of SerializationStreamFactoryMBean where we set and get the serialization manager from the factory.

3. Based on the serialization type specified in step 1 we can invoke the either JBossSerializationManager or JavaSerializationManager (default) to create the needed MarshalledValue to serialize the objects

Thoughts?

-Hany

[brian.stansberry]

For now, I'm not even sure I want this end-user configurable. I as a developer currently need it configurable so I can easily benchmark the effect of using JBoss Serialization. Based on those results we can then decide if we want it to be end-user configurable. But for my temporary purposes configuration via a system property is more than adequate. So, as we discussed, please do it that way. Go ahead and invent any property you want, just make sure it's prefixed with 'jboss.'

If we later decide we want it to be end-user configurable I'd lean toward #1. The difficulty with #2 is a JBossCacheManager isn't a regularly deployed MBean service where you can dependency inject. The dependency injection would be to the Tomcat service, and TomcatDeployer would then have to programmatically pass it into the JBossCacheManager. I'd prefer not to do that, as 1) it makes Tomcat service more brittle by adding a dependency that's only needed for a specialized case and 2) it further couples the deployer and the manager.

[brian.stansberry]

I *knew* I remembered something about a system property somewhere :)

It's in JBoss Cache. They're using system property "serialization.jboss"; let's do the same for now.

[hmesha]

hi Brian,

I've invented my a new system porperty session.serialization.jboss=true (default) / false :) . Also, taking into account Clebert advice to use factories. I'll create org.jboss.web.tomcat.tc6.session.SessionSerializationFactory class similar to the factory in JBC but it doesn't override the default implementation to change class loader context since we already deal with it inside http session replication code. The class reads the system property mentioned above and sets the boolean value UseJBossSerialization and static methods to create ObjectOuputStream, ObjectInputStream, MarshalledValue, MarshalledObject. Those methods will be used in conjunction with UseJBossSerialization falg to serialize the objects in JBossCacheService before inserting into the cache and deserialize after returing a retrieved value.

[brian.stansberry]

Sounds good.

[hmesha]

Should we duplicate this implementation to tc5 package? Also, would we want to create session serialization benchmark tests?

[brian.stansberry]

Nah, don't port to tc5 package. I'm not sure why that even still exists; I expect it will be deleted.

Re: tests, we have a framework we use in our cluster lab; simplest is just to stick with that for now.

[ricardoarguello]

I need to backport this to JBoss 4.0.x.

How should I proceed? Can I use the same SessionSerializationFactory class from JB5, and just modify JBossCacheService in the 4.0.x Branch. I have read the source code and it looks like this should work...

Thanks

[brian.stansberry]

From a quick look it seems that should work fine.

[hmesha]

Yep. It should work fine. All you need to change, in addition to backporting the SessionSerializationFactory, in JBossCacheService are the calls that are invoking marshalling.

-Hany

[ricardoarguello]

I have backported JBAS-2921 to 4.0.5.GA, but I have one problem: ClusteredSession.canAttributeBeReplicated() will always return false if the attribute does not implement Serializable. Was this supposed to be used with FieldBasedClusteredSession only?

Ricardo Argüello

[hmesha]

for any attribute to be replicated, it must implement serializable. Regardless of the session replication policy in effect. JBossSerialization implmentation is meant to be used instead of Java Serialization for replication and not meant to deal with non-serializable attributes.

It's possible to use JBoss Serialization to serialize non-serializable before replicating them but that require further developement and it was beyond the scope of JBAS-2921.

[ricardoarguello]

I see...

Serializing non-serializable objects was my original idea. I know JBoss Serialization can do that, maybe I'll develop this functionality for JBoss 4.x and 5.0.

I have added an issue: http://jira.jboss.org/jira/browse/JBAS-4524

[brian.stansberry]

Focus on AS trunk (i.e. 5.x). For now I want to very much restrict new feature development in Branch_4_2. Branch_4_0 is definitely bug-fix only.

Suggest you start with a post on the JBoss Serialization forum to check the status of support for serializing non-Serializable classes; i.e. how stable, is it being actively maintained or developed, etc. From what I understand, in the more recent JDK 5 releases, standard JDK serialization has fixed the stuff that had made JBoss Serialization more performant. So, one reason for ongoing work on JBoss Serialization is gone. Before introducing a feature to JBoss AS that depends on a JBoss Serialization feature, I want to be sure that the JBS feature is stable for the long term.