tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: mod_jk release policy - was: JK 1.2.9-dev test results
Date Fri, 18 Feb 2005 09:44:13 GMT
> So I don't see the point of forking 1.3. Both config and core features
> are the same. Of course some advanced configuration properties where
> changes, lot new added, but from the outside its still old mod_jk.

OK, understood from below. I agree concerning JNI deprecation. But read 
comments about local_worker.

> Regarding locality, you mean local_worker and local_worker_only flags?
> IMHO that was one of the fuzziest things about jk that no one ever
> understood, not to mention that this never worked actually.

You are totally right about the bad documentation (at least concerning 
the status before you gave it a refresh). But I have the feeling that 
more people where using it like me, by studying the code (at least it's 
open source) and learning the functionality from there. So local_worker 
is a feature, that I assume is being useful and used.

> So locality is not deprecated. Quite opposite, now it works, just
> the local_worker_only is changed to sticky_session_force.
> IMHO this is more clearer and descriptive directive then previous one.

My understanding of the use case: the term local_worker historically 
most likely comes from the idea, that if you use multiple systems each 
with apache and tomcat on them, then a call from an apache to the tomcat 
on the same system would be faster then going to a remote tomcat. 
local_worker should have indicated to prefer this (until 1.2.6 only one 
worker would work as a local_worker) worker unless a request carries a 
session id and stickyness is on or the local_worker is in error state. A 
more general better term would have been preferred_worker or just 
preferred and that's the way it is used today. At the moment there seems 
to be no more possibility to map a preference (I don't mean load 
balancing weights).

Still I know cases, where it makes sense to have a distinction for 
requests without session id/stickyness between:

- preferred (one or more)
- failover for the preferred (your redirect)
- maybe allowed (although the first two cases should be enough not to 
need more)
- the rest

"The" rest is there, because some worker may only be used, in case 
stickyness comes in.

With stickyness and session id one would have:

- sticky worker (the correct one)
- failover for the preferred (your redirect)
- any other in the same replication cluster (domain)
- the rest (loose session but can start the app again from the beginning)

Your redirect concept and my older domain patch share some use cases.

On the other hand local_worker_only only makes a difference if you 
configure local and non-local workers in a load balancer and all local 
workers go into error state. With local_worker_only, all further 
requests will fail. Without local_worker_only the non-local workers will 
be used. I always had the impression that only very few - if any - 
people will need this kind of feature.

You indicated i a separate answer, that one could use the disabled 
attribute instead. But I assume there is no failover to a disabled 
worker, whereas there should be to a non-preferred worker.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message