-
1. Re: Excessive UDP packes when serialising a session
slaboure Oct 10, 2002 3:42 AM (in response to alt1)Which kind of codebase do you have? I should only have one URL in it.
I am curious to have an answer to this question while I agree that we don't need to serialize this information as part of the state.
I may take a look into this when I have time. I think someone already wrote a non-verbose marshaller, so it would be very easy to plug it in.
One of my next goals is to work again on the HttpSession clustering side to improve it. -
2. Re: Excessive UDP packes when serialising a session
alt1 Oct 10, 2002 8:01 PM (in response to alt1)Hi,
You are right the codebase is a single URL contained in the MarshalledObject object. However I have rebuild JBoss with an altered ClusteredHTTPSessionBeanImpl.java. It now writes the serialised stream to a filesystem object. This object turns out to be approx. 120K. The majority of the file is the complete classpath of the application replicated around 6 times. This includes items in tmp/deploy/server/all/deploy/ folder. The ones that have numbers pre-pended. Each element is space separated. It actually looks like a serialized array of Strings.
If I remove the MarshalledObject then the size drops right down to a few 100 bytes.
Everything then works OK (session replicated) until the first session expires. At which time the session object tries to be de-serialized (all tied up with the EJB lifecycle stuff). This fails since the Thread that is doing the session reaping does not have access to the classes contained in the serialized object and hence fails to load it. (Class loading failure!).
Oh dear :-( -
3. Re: Excessive UDP packes when serialising a session
alt1 Oct 10, 2002 8:05 PM (in response to alt1)Hi,
You are right the codebase is a single URL contained in the MarshalledObject object. However I have rebuild JBoss with an altered ClusteredHTTPSessionBeanImpl.java. It now writes the serialised stream to a filesystem object. This object turns out to be approx. 120K. The majority of the file is the complete classpath of the application replicated around 6 times. This includes items in tmp/deploy/server/all/deploy/ folder. The ones that have numbers pre-pended. Each element is space separated. It actually looks like a serialized array of Strings.
If I remove the MarshalledObject then the size drops right down to a few 100 bytes.
Everything then works OK (session replicated) until the first session expires. At which time the session object tries to be de-serialized (all tied up with the EJB lifecycle stuff). This fails since the Thread that is doing the session reaping does not have access to the classes contained in the serialized object and hence fails to load it. (Class loading failure!).
Oh dear :-(
(Reposted - not sure first post worked OK) -
4. Re: Excessive UDP packes when serialising a session
slaboure Oct 11, 2002 4:55 AM (in response to alt1)Hello alt1,
That's interesting. What do you mean by "If I remove the MarshalledObject"?
And do you have the stacktrace of the classloading exception?
That's really interesting because it has two consequences:
1) if the size is soooo big, then we can really improve performance by replacing MO with something less verbose (easy)
2) if, when you remove MO, you get classloading exceptions, it *may* mean that it also fails now and the reason we don't receive an exception is that dynamic class downloading is used => VERY BAD in this case as it really impact the cluster performance.
If you can give me more information, I will work on this.
Cheers,
sacha -
5. Re: Excessive UDP packes when serialising a session
alt1 Oct 12, 2002 2:33 PM (in response to alt1)Hi,
The MarshalledObject, as I understand it, is only a "place holder" for an object. Looking at the code it is never used as a MarshalledObject only the fact that it implements the serializable interface. So all I did was just store and extract session object directly in "this.tmpSession". I have attached the very small patch that demos this.
I have also attached a stack trace when the session times out. This only occurs on timeout of the session.
Note that with the patch applied I have not tested that another member of the cluster can actually deserialize ithe session objects, but I have observed the serialized object on the network.
The patch will only work if the thread that does the deserialization has all the required classes - if not the bad situation of dynamic class downloading you described would occur for every serialization - in which case the patch will cause bad stack dumps other members of the cluster. oooppss.
Andy. -
6. Re: Excessive UDP packes when serialising a session
slaboure Oct 14, 2002 5:56 AM (in response to alt1)OK, I see what you meant by removing MO. In fact, I use a MO for a simple reason: as long as you use sticky sessions, the replicated session is received by other nodes but *never* unmarshalled until it is really needed (this, to save CPU time creating potentially lots of small objects)
Thus, I will replace the MO by another, less verbose MO but I will still use it to save CPU.
Do you have more information WRT to "if the thread that does the deserialization has all the required classes"? If your applications is deployed on all replicated nodes, that should automatically work thanks to the UCL. Is that the case? I guess you got that CNF exception because you hadn't deployed the applications on all nodes, correct? In this case, the same exception would have occured with the MO but, as we use late-deserialization, only when the node would have tried to unserialize the session, not before (which means NEVER if the web application wasn't deployed on this node) -
7. Re: Excessive UDP packes when serialising a session
alt1 Oct 14, 2002 6:14 AM (in response to alt1)Hi,
The stack trace was obtained from the same machine that the app was running on. In fact I had only one instance of the JBoss/JVM running. I could tell it was trying to do the session replication because of the multicast network traffic.
"if the thread that does the deserialization has all the required classes" - I was thinking here that if the session timeout thread was not a part of any particular application i.e one was used to timeout all/any sessions running in a container, then it is possible that its class loaders would not have access to the apps classes. I must admit that I don't known fully how the Class Loaders work in JBoss but I have alot of experience in writing and using class loaders else where & can guess where things fall apart (I've been there!).
Since I don't get this stack trace when using the MO It maybe that even the same JVM is using the dynamic class loading stuff when timing sessions out???