Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: softfail (athena.apache.org: transitioning domain of
 pid@pidster.com does not designate 209.85.219.220 as permitted sender)
Message-ID: <4B4CB11C.7000908@pidster.com>
Date: Tue, 12 Jan 2010 17:27:56 +0000
From: Pid <pid@pidster.com>
Reply-To: pid@pidster.com
Organization: Pidster Inc
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: users@tomcat.apache.org
Subject: Re: More on Tomcat Sessions - limiting cluster session replication
 to sessions that will last longer than 'n' duration
References: <85FA03E6BB6F0340B5A117013571A9B70469B4AB@exchange3.ad.sis.tv>
 <6B028542C4A77D4CB7F06CCC1C1AEB1D055A5168BC@AUSP01VMBX03.collaborationhost.net>
In-Reply-To: 
 <6B028542C4A77D4CB7F06CCC1C1AEB1D055A5168BC@AUSP01VMBX03.collaborationhost.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org