Jess Holle wrote:
Agreed, but this is concerning *both* mod_jk and mod_proxy and I've
been scolded for cross posting...
At the core, I'm looking for 2 things:
1. Something to limit the maximum impact of having many dead
workers under a load balancer on normal requests
* Assuming there are live workers available, of course, i.e.
the process of discovering that dead workers are still
dead shouldn't overtly impact any normal request.
* Sample situation: load balancing over 9 ports, many of
which do not have an active Tomcat associated at the
time. If there is only one Tomcat alive every 'retry'
seconds (in the mod_proxy case, same thing, but different
parameters for mod_jk), a normal request is delayed by a
period of 8*dead-connection-latency. That's neither
necessary nor acceptable.
* Possible solutions include having a background thread ping
the health of workers rather than allowing normal requests
to do so or limiting the number of workers any normal
request will attempt to recover.
Clearly if we take the approach of a backgroung ping solution, it would
be ideal to use cping rather than any sort of real request.
1. Something to reduce the severity of log messages when
discovering that a dead worker is still dead.
* There is no need to fill the error logs with notices that
a worker that has been dead is still dead. This is good
troubleshooting info and should be logged, but at a lower
severity level that does not show up in the logs by default.
* Depending on the solution to (1), this might just fall out
of that.
If you believe we should start up a discussion on httpd dev as to how
to solve these issues at this point that sounds great to me -- though
we also need to solve them in mod_jk (as our current plan is to use
mod_proxy_ajp for Apache 2.2 and we have no alternative but the
jk/isapi connector for IIS).
Also to be clear I need solutions to these problems one way or another,
so if nothing else I'll have to hack in something into our own fork of
the code.
I have a fair amount of time to solve these problems, however, so I'd
much rather see them solved in a good, general way that can be a
value-add part of mod_jk and mod_proxy -- rather than a one-off fork.
--
Jess Holle
