On 12/01/2010 16:47, Robin Wilson wrote:
Earlier this week I posted a question about how to prevent sessions from being
created in our Tapestry pages, and/or how to get Tomcat to get rid of a bunch
of '1-second' sessions we're creating during a load test because the sessions
eventually fill up the heap. (They are being created faster than Tomcat can
clean them out - even though they expire faster than we create them.)
So, my lead developer thinks he has found a way to alleviate our problems (at least for
our production Tomcat 6.0.20 cluster of 4 servers). We will not replicate sessions to
other cluster members unless they have a duration longer than a 'threshold' we set. We
are altering the DeltaManager to make this change, so that simply creating a session
doesn't automatically guarantee that it is replicated to other nodes in the cluster. The
session duration will also have to be greater than a
"sessionDurationMinThreshold" value we will set in the 'server.xml' file for
the new DeltaManager. The idea is that sessions created that have very short durations
are really 'transient' anyway, so there is no need to pass them off to the other members
of the cluster.
The question I have, is there anything we should watch out for in making this adjustment
to the DeltaManager? We will test this pretty heavily before we deploy it to our
production environment, but I'm worried about things we should be looking for in that
testing (other than just validating that our "useful" session data can be
available across multiple cluster members).
Robin, please post a new message when starting a new thread.
When you reply, even if you edit the subject line & content, the
In-Reply-To header is still set & so, in a threaded email view you have
responded to a different thread.
(See "Thread-hijacking".)
p
--
Robin D. Wilson
Director of Web Development
KingsIsle Entertainment, Inc.
CELL: 512-426-3929
DESK: 512-623-5913
www.KingsIsle.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
