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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
