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 Tue, 19 Feb 2008 22:38:02 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-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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message