tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Tuning session replication on clusters
Date Thu, 06 Sep 2012 15:09:14 GMT
On 06.09.2012 16:57, Rainer Jung wrote:
> On 06.09.2012 15:10, wrote:
>> ...  This actually didn't surprise me after I
>> discovered how large the sessions were.  Using JMX (VisualVM) I
>> watched the
>> Heap size on my two servers as I tested 7000 sessions.  Heap climbed
>> approximately 1GB.  When I restarted node2, I watched node1's heap usage
>> nearly double.
>> This confirmed my suspicion that the replication process is putting a
>> copy
>> of all sessions into a new object (list I suppose?) before transmitting
>> them.  After replication finished (109 seconds), node1's heap usage went
>> back to normal.
> That's a plausible explanation for your observation. You can split
> replication in several chunks using the config items you already
> observed. Even in TC 6 the DeltaManager supports:
>      sendAllSessions (Default: true, means all session send in one
> message, false means split in multiple messages)
>      sendAllSessionsSize (Default: 1000, number of sessions send per
> message when switch is false)
>      sendAllSessionsWaitTime (Default: 2000; sleep pause between sending
> consecutive messages)

I forgot one more thing: since TC 6.0.34 and 7.0.22 is it possible to 
decide which session attributes get replicated. So in case you have only 
few attributes that make up most of the big session memory *and* your 
application is able to transparently handle the situation, that these 
attributes are suddenly missing from the session, e.g. by retrieving the 
data again from some back end system or database, the following might help:

Look for sessionAttributeFilter in

I'm not saying it is easy, but if you want to make your application 
using session replication really efficient, it is a possible way to go.

In addition there is a way an application can detect whether there was a 
node fail over, ie. a request is handled by another node as the previous 
request for the same session. You can hook filling missing attributes on 
this detection. The detection uses a feature of the ReplicationValve, 
which can set a request attribute that can be inspected to decide 
whether there was a fail over. Look for primaryIndicator in If 
the attribute is false, you just switched nodes (fail over) and are now 
working on a replicated session.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message