DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=37247.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37247
--- Additional Comments From [EMAIL PROTECTED] 2005-10-26 09:26 ---
I can also confirm that we've seen the same thing under mod_jk 1.2.14 and
Apache 2.0.50 (prefork) on 32-bit linux. Using mod_jk Pessimistic mode
instead of optimistic may have helped some, but it the problem still happens.
The opposite also happened to us -- worker busy values were set to values near
MAX_INT, possibly due to being decremented too many times, ending up below
zero and wrapping around.
Our algorithm in the 'busyness' load balancing patch (see bug 36138) depends
on the worker busy values, so we put in a quick and dirty fix in that patch
that sets the busyness value to 0 anytime it gets below 0, but this doesn't
help the case when it gets stuck higher than it should be. See also the 4th
and 5th paragraphs in the first comment of bug 36138.
I think the busy value may have been initially added only for display
purposes for the jk_status page, so keeping the busy values accurate may not
have been very important initially.
Finally, if you do an apache graceful restart under load, the mod_jk busyness
values are usually all messed up.
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
