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]
