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 02:25:44 GMT
Jess Holle wrote:
> Jess Holle wrote:
>> Mladen Turk wrote:
>>> Jess Holle wrote:
>>>> Mladen Turk wrote:
>>>>
>>>> Is there a means of achieving background-only (or nearly so) 
>>>> testing of dead workers with mod_jk?  That's what I'm looking for 
>>>> in both jk and mod_proxy_ajp connectors.  I guess I was 
>>>> hoping/assuming it was there in mod_jk from reading the docs.
>>>>
>>> There is in the mod_jk (SVN trunk).
> I've been reading this code now...
>
> The watchdog thread looks very useful.  If I understand it correctly, 
> the watchdog thread can do whatever it feels like but currently mainly 
> calls wc_maintain, which will only do work at most every 
> worker.maintain seconds, right?
>
> connection_keepalive does not look like it really my bill, though.  
> I'm most worried about workers in an error state and ensuring that 
> they are rechecked every recover_wait_time -- but only by the watchdog 
> thread and ideally via a ping/pong.  Currently recover_workers appears 
> to just put workers into a recovery state where they'll be elligible 
> to be tried again on a future request -- without checking whether the 
> worker is actually accessible.  That's fine for some use cases, but 
> explicitly what I want to avoid.
>
> Are there any thoughts to have an option to have recover_workers() do 
> a ping prior to returning a working to a non-error state?
>
> And, yes, a watchdog thread in mod_proxy_balancer /and /a reasonable 
> means of balancer invoking a ping via mod_proxy_ajp would be really 
> helpful as far as mod_proxy_ajp is concerned.
Another possibly simpler alternative: we could introduce a limit as to 
how many workers we attempt to do (unforced) recoveries on for any given 
request.  Any request could likely tolerate a recovery attempt or two.  
None should have to tolerate 6-12 recovery attempts just because of a 
currently sparsely populated port range.

Thoughts?

--
Jess Holle


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