tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rainer Jung" <tomcat-u...@kippdata.de>
Subject Re: session problems when using mod_jk (1.2.14) load balancing
Date Thu, 18 Aug 2005 21:06:06 GMT
OK, thanks Mladen: I have to correct myself.

1) Traditional use

Until mod_jk 1.2.6 there was no concept of domains. You had to specify the
worker name to be exactly the same as the jvmRoute to make sticky sessions
work. This way of configuring stickyness is wel known to mod_jk users.

2) I introduced domains to allow mod_jk to make good failover decisions in
the case where you have many tomcats, but session replication only between
subset, like 2 Tomcat clusters with three instances each (T1_1, T1_2, ...,
T3_3) where T1_1, T1_2 and T1_3 replicate their sessions between each
other etc. Then you can configure a common domain name for T1_1, T1_2 and
T1_3 (e.g. T1) and is mod_jk is not able to correctly route a sticky
request (e.g. T1_1 goes down) it will choose another worker with the same
domain name. Moreover in this case it will load balance betweeen all those
workers (in my example between T1_2 and T1_3).

1) and 2) still work in 1.2.14.

3) Mladen improved mod_jk a lot and during that time introduced another
additional way of using the domain attribute: If stickyness for sessions
is required and mod_jk does not find a worker with the name of the
jvmRoute contained in the session id, then it will next try to find any
worker whose domain name is equal to the jvmRoute. If there are multiple
such workers, mod_jk loadbalances between them.

Summary: If there is a one-to-one relationship between jvmRoutes and
workers, there is no functional difference between giving the worker the
same name as the jvmRoute, or giving it the same domain attribute as the
jvmRoute. The first way is more compatible with what people used to do
since a long time and it will be marginally faster, because that check is
done first.

It's always good to look at the code, in fact when I first discovered the
use of the jvmRoute as a domain name in the code I thought it's a bug. I
now understand, that it's at least a feature :-)


> Hi Mladen,
>
>   I've used the domain property because it seemed the more general
> approach (i.e., supports clusters but can be used with a single worker).
> What this thread got me curious about is if using the domain property in
> this fashion is "officially" supported, or on the other hand if it can
> only be used reliably with clusters.
>
>   After reading the documentation
> (http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html), I
> got the idea that using the domain property with only one worker
> wouldn't be a trick but another way tell mod_jk which jvmRoute to use:
> "If sticky_session is used, then the domain name is used as session
> route.". Naming the worker after the intended jvmRoute (even though it
> used to be the only way) seems more of a trick than explicitly
> specifying the jvmRoute with the domain property.
>
>   However, since the same documention mentions that the domain property
> is used for large systems with clustering, do you know of any side
> effects (like lower performance) of using this approach as opposed to
> simply naming the workers after the jvmRoute?
>
>   -- Edgar Alves
>
> Mladen Turk wrote:
>
>> Edgar Alves wrote:
>>
>>> Hi,
>>>   I'm using the domain property in the same situation as the one
>>> discussed in this thread. Any reason why I shouldn't use the domain
>>> property and rely on the worker names instead?
>>
>>
>> Domain is supposed to be used with multiple workers sharing the
>> same jvmRoute having session replication between them, thus
>> forming 'cluster groups' to lower the session data replication
>> transfer.
>>
>> You can use the domain, but it's a trick rather then a proper
>> usage.
>>
>> Regards,
>> Mladen.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>



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


Mime
View raw message