Hello Rainer; Thanks. So if I have it right, sorry if I keep repeating whats been stated already, all the load-balancer algorithms are not really checking node health as in JVM Memory usage, CPU usage or Threads used at any given time (which I believe is a feature in a future mod_jk ? ),
Only checks the Network Latency (Network Response ) through Cping and Cpong methods as a nodes health as described in http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html Regards Mohan Rainer Jung-3 wrote: > > 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] > > > -- View this message in context: http://www.nabble.com/mod_jk--%22Busyness%22-algorithm-and-Node-Health-Check-tp14650298p14663038.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
