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=44454>. 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=44454 ------- Additional Comments From [EMAIL PROTECTED] 2008-02-19 14:38 ------- Thanks for the check, so we know for sure, that the busy count doesn't correspond to the backend status. Although there is still a theoretical possibility, that mod_jk *thinks* the backend is that busy, I checked, if we miss some error conditions when decreasing the busy count. There is not condition in the code, how the busy increment could not be followed by a decrement. The counter is hold inside a shared memory segment and it is marked as volatile. In case you hae a *very* busy web site, it's possible, that we run into a non-atomic increment/decrement problem. Although that's possible, I'm still thinking about other possibilities. The status worker shows a busy counter for the lb and for each member of an lb. Do both types of busy counters suffer from the problem? To get an idea: how fast does the problem happen (how much busy increase per day or so, and also how many requests approximately are handled by the corresponding worker during that time)? You mentioned, that this influences negatively the balancing behaviour. I deduct from that, that you are using the Busyness method. Do you have a reason not to use the Requests method? It would not suffer from the "wrong busy" problem. Finally: although we know no change in the code that would suggest that the problem will go sway in 1.2.26, is it possible to switch to that version? Be careful: in 1.2.26 your JkMounts are not automatically inhertited between httpd VirtualHosts. You either need to include them in each VirtualHost or use JkMountCopy (see docs). Apart from that, the version update should be reliable. I'm still wondering, if mod_jk threads might hang between start of request and end of response. You could use gstack, to do thread dumps on the httpd side. Since the busy number is summed up over all httpd child processes and we don't know if the problem is located in only one of those or visible in all of them, you would need to do gstack on all httpd child processes. The ones busy in mod_jk will be easily detectable, since mod_jk uses "jk" as part of most function names. -- 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]
