On 06.09.2012 16:57, Rainer Jung wrote:
On 06.09.2012 15:10, kharp...@oreillyauto.com 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
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-manager.html
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
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-valve.html. If
the attribute is false, you just switched nodes (fail over) and are now
working on a replicated session.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
