Jim Jagielski wrote:
On Aug 28, 2008, at 12:41 AM, Mladen Turk wrote:
Jess Holle wrote:
P.S. I'd also like to quiet attempts to recover workers from errors
to a lower (and by default unlogged) logging level. The transition
of a worker into an error state should certainly be logged, but
logging every time we find it to still be in an error state seems to
be excessive -- at least for a sparsely populated port bank use case.
Everything you said is fine with me. I just did a functional
logic via watchdog thread and two basic use cases (maintain
and keepalive). The keepalive is meant to deal with firewalls
that tends to cut inactive connections.
As far as I'm concerned feel free to extend the logic so
it can deal with error states more intelligently.
... and of course, the plan is to implement something or
all of this to mod_proxy, but using a different mechanism.
Many modules needs some sort of out of the request cycle
detached maintenance, so I'll add a common mpm maintenance
thread to lower down the resource usage.
Ummm... since this is regarding mod_proxy, all this should be on
the httpd-dev list, and not on the Tomcat dev list...
What is, or is not, included in mod_proxy is what the httpd dev
community decides :) :)
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.
2. 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).
--
Jess Holle
