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