Hi Mohan,
Mohan2005 schrieb:
Dear All;
If I am not wrong, the "Busyness" algorithm routes requests to workers by
checking their "Health"
What criteria constitutes as a "nodes" "Health"
and if so,
How is it determined (using the native JVM or else )
All balancing methods of mod_jk share common aspects:
1) Don't send requests to workers, which are in error
Workers go into error state, whenever mod_jk detects a failure during
request processing with that worker.
Which failures depends on the jk configuration. Mostly they are timeouts
and network problems.
2) Use stickyness instead of load based balancing if not disabled
3) Decide about requests without sessions based on the load value of the
workers, which are not in error
What's the load value?
That depends on the balancing method.
- method "Request" (default): increase the load value of a worker by one
for each request send to the worker and divide by two all load values
every now and then (app. once a minute). So the load value is the
comulative number of requests handled by the worker with a envelope
curve that counts older requests less than more recent ones. This method
tries to keep total work balanced.
- method "Session": the same as Request, but do only count a request, if
it didn't contain a session cookie or URL encoded session. It is not the
same as actually knowing how many sessions each backend has.
- method "Busyness": load value is the number of requests currently
being processed by a worker. For example when load is low, most or all
workers will have load value "0". This method tries to keep concurrency
balanced. It will not be good in balancing total work.
So: the health aspect is not special to method "Busyness". One could
argue, that if one node gets slow, the concurrency will go up soon, so
Busyness includes a good prevention for overload. On the other hand,
using "Request" with a reply_timeout will also lead to such a
prevention, because then a node that has overload will be put
temporarily into error state.
Mod_jk has no internal knowledge of the backends state, like Memory,
Thread counts etc. It can only judge by the symptoms observed during the
response handling (no connect possible, no cpong answer to a cping,
response took longer than reply_timeout etc.).
Whenever such a type of error is detected, the jk log should contain an
error log line with an indication of the type of error. With JkLogLevel
info you might get (info) log lines even if there is no hard error, but
in case of a real error, you will get additional information about the
root cause.
Thanks you
Regards
Mohan
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
