Rainer Jung wrote:
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.
Yes, I took your patch as conceptual start point.
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.
Well you have sticky_session_force. If the worker that has that session
is in error state then first the redirect (preferred) will be checked.
If this one is in error state too, the domain will be checked and
if not set or all are in error state 500 will be returned.
(Meaning: we don't have session replication and wish to brake in
case of failure)
If sticky_session_force is not set then other worker will be chosen
with loosing session.
(Meaning: we don't have session replication but wish to continue anyhow)
So you have two basic sticky_session concepts:
with or without session replication,
and that is what sticky_session_force determines as well how the
session loosing is treated.
The same applies when you have multiple domains. Then each domain
or group is treated as single worker and all rules mentioned above
are in place.
What is missing perhaps is a flag to indicate whether the worker name
or domain name will be used as service jvm route.
That way you could group workers without session replication in place.
(Putting workers on top of list concept). But then you don't need
the domains at the first place.
If you think some nodes (like local one) are faster, then simply use
higher lb_factor for those nodes.
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.
Disabled can be initially set for hot-standby. If set to on only the
requests with matched session id will be processed.
Regards,
Mladen.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
