tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 44454] - busy count reported in mod_jk inflated, causes incorrect balancing
Date Wed, 20 Feb 2008 17:46:45 GMT
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 rainer.jung@kippdata.de  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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message