tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: mod_proxy_balancer issue
Date Thu, 28 Aug 2008 13:47:16 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message