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 (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4A534C11.4070109@ice-sa.com>
Date: Tue, 07 Jul 2009 15:22:25 +0200
From: =?ISO-8859-15?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
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> <4A525037.1070907@kippdata.de>
 <4A534980.5060503@technisys.net>
In-Reply-To: <4A534980.5060503@technisys.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Emilio Recio wrote:
> Rainer Jung wrote:
>> 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
>>
>>   
> Hi, Mark. Thank you very much!!! Your replay was very useful. But i 
> still have some doubts.
> When we use clustering, we gain in  availability. Otherwise you gain in 
> performance.
> The doubt is: Which is the purpose of the STICKY SESSION in a clustering 
> system. The only thing we know is the fact that stickiness  only  attach 
> a  client session to only one tomcat over the life cycle.
> Thanks very much.
> 
It seems to me that you have a complete, in-depth explanation of this 
above from Rainer, starting with "Why use sticky sessions..".  Did you 
really read it ?


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