Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4A525037.1070907@kippdata.de>
Date: Mon, 06 Jul 2009 21:27:51 +0200
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de;
 rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Sticky session and ModJK Load Balancer
References: <4A523116.2000604@technisys.net> <4A523597.7060806@apache.org>
 <4A524202.7010704@technisys.net>
In-Reply-To: <4A524202.7010704@technisys.net>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

On 06.07.2009 20:27, Emilio Recio wrote:
> Mark Thomas wrote:
>> Emilio Recio wrote:
>>  
>>> Hi,
>>> i have installed Apache 2.2 and two Tomcat 6 whit load balancing in
>>> cluster mode using "mod_jk" module and setting sticky session in TRUE,
>>> and memory replication. I was testing my project and work perfect.
>>> We have a dilemma using sticky session or not using it, with my team
>>> work.
>>> Setting sticky-session in TRUE, it works fine, even when one tomcat
>>> fails-over. When set to FALSE i can see that the session have some data
>>> loss, and the project start to fail.
>>> I was reading the book Professional Apache Tomcat 6, goggle searches and
>>> all kind of information in the net. The recommendation is: use
>>> sticky-session in TRUE with memory replication.
>>> Nobody mention concrete arguments, and need that to make a report to the
>>> system administrator, to make him understand why we need to use
>>> sticky-session in TRUE.
>>>     
>>
>> I would have thought the occasional data loss you see is argument
>> enough. What more were you looking for?
>>
>> Mark
>>   
> Hi Mark,
> We are developing an e-commerce app. The application store  in session a
> lot of information like user data, user history data, etc.
> The scenario is: 3 PC's, one with Apache 2.2, and the others have Tomcat
> 6. Apache has mod_jk to make load balancing, and the Tomcat 6 have
> configured in memory session replication, to support fail-over.
> STICKY SESSION FALSE:
>    Some times: Tomcat1 after the login, has all the user info charged in
> session, when load balancer try to use the Tomcat2 some info is saved
> but other info is missing.
> We need to know good arguments to justify to the client, why we should
> use sticky session in true to avoid this missing data issue. The client
> doesn't want to use sticky session in TRUE, they arguments are: "We
> loose performance in transactions and loose of loadbalancing (using
> sticky session in TRUE). Using sticky session in FALSE the Tomcat more
> idle attend the request that incoming and gain performance. One example:
> You have 4 users, two in tomcat1 and the other two in tomcat2. If users
> in tomcat2 logout, this stay idle when the other is attending the other
> two users. So, you "loose load balancing"."
> 
> They arguments are partial true, using stick-session in TRUE , you have
> one tomcat attending a client session during its life cycle; even if
> this users are idle or has very active session. Its stable and fail-over
> tolerant. Of course you "loose" performance.
> So we need good arguments to explain why we need use, sticky session in
> true.
> My regards,
>    Emilio  Recio

Usually you only use a custering solution like Tomcat session
replication if you really need high availability. Clustering adds some
complexity to the system, so in order to justify that you need a reason,
which should be, that your user sessions are expensive, so you do not
want to loose them under any circumstances.

If so, your primary goal is stability not performance. Adding any high
availability solution also reduces performance (but maybe only a bit).

Why use sticky sessions when doing session replication? Because without
sticky sessions, each request depends on the fact, that the replication
of the previous request to the same session was completed successfully.
So the correctness of your application depends the whole time on the
completeness of the session replication (because requests will switch
form node to node a lot without stickyness). Whenever something goes
wrong with respect to session replication, a user will fail. This seems
to be, what you actually oberve when working without stickyness. Your
application is *not* replicating completely. Stiky off is a good setting
for testing, but not for production.

With stickyness, under normal operation you don't rely on the fact, that
replication works. Only in case a node goes bad, the sessions fail over
and then you need the correctness of the previous replications. Usually
this only happens unplanned like maybe once a month or even fewer times.

It is also much easier to track what's going on and maybe wrong, when
you have stickyness, because then all requests for one session can be
usually found in the log files of only one node. You don't have to
consolidate them from multiple nodes.

Concerning performance: If you only plan 2 Tomcat nodes, then you have
to size the in order for one node to be able to carry the full load.
Otherwise when a node crashes, although you have session replication, it
could happen that the remaining node is not able to cope with the load.
So an uneven load distribution between the two nodes is not a real
problem, each one should be able to handle all requests.

Under high session load (like e.g. more than 1.000 users logged in)
usually the request load distributes good enough to not produce a very
uneven load.

In short: stability is more important then performance in
high-availability situations and a two node cluster should be designed
such that a single node can carry all the load.

Concerning only one Apache node: that doesn't look like high-availability.

Regards,

Rainer

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