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-20 09:46 ------- So unfoirtunately we now *know*, that the number is wrong, i.e. it doesn't reflect the internal state of mod_jk. I had the hope, that 68 was already the inflated value. That means: all my comments on reply_timeout are true, but will most likely *not* help about the wrong busy values. So I'm a little clueless on how to proceed further ... With the busy count in the access log, we could see, if the unwanted increase in busy mostly happens during busy hours (assuming that your load is not totally equally distributed over the day). If we really have a problem with non-atomic increase/decrease, we should expect that to happen mostly during the peak hours. Possible workarounds: - don't use lbmethod busyness (yes I know, you've got good reasons to use it, but unfortunately also one reason to not use it) - (gracefully) restarting the web server. If you can live with the problem for a day, you could restart the web server once every night. Caution: this will reset all settings changed in mod_jk via the status worker during the day back to the values configured in the config files, e.g. activations status (disable, stop). - I could find out, if oine can easily change the busy value from the outside in the shm file. Of course we don't know the correct busy value, so we could only reset to 0. If we decrease the value in mod_jk and it would get below 0, we keep it at zero. So there is some chance, that after resetting it to zero, it will get close to the correct number after some time (we would only need a short moment were statistically load is low). No really nice option available at the moment ... How many threads per process do you have configured for the MPM? 60? No advise on enable-flock. Do you think you could reproduce with a simple test scenario? This would open up the opportunity to test patches. As I said, we can't reproduce and I don't know of any other such case. -- 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]