> 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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
|