tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Sticky session and ModJK Load Balancer
Date Tue, 07 Jul 2009 13:22:25 GMT
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.
>>>    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:
>> For additional commands, e-mail:
> 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:
For additional commands, e-mail:

View raw message