tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject mod_proxy_balancer issue
Date Mon, 25 Aug 2008 23:44:47 GMT
I want to use mod_proxy_balancer to load balance over a set of ports 
that potentially have Tomcats running on them.

Unfortunately there will generally be a good number of ports where no 
Tomcat is running.  Every 'retry' seconds I have a request that takes 
about an extra second for each Tomcat-less port, which is not acceptable.

Has there been any thought or effort to provide an option to retry 
dead/unresponsive members in a periodic background thread instead of 
with normal, "live" requests?  I am currently very interested in adding 
such an option if none exists, so I'd appreciate any thoughts on the matter.

I also need to support the mod_jk-based IIS/Tomcat connector in the same 
scenario, but have not yet investigated how this will work out.  
Thoughts would be appreciated here as well.

If mod_jk would work better than mod_proxy_ajp this presents me with a 
couple of issues:

   1. The ability that mod_proxy_ajp has to queue/backlog requests when
      all workers are busy rather than returning an immediate 503 is
      highly desirable here.
   2. As an integrated part of Apache, mod_proxy_ajp is in many respects
      the future here and I'd rather improve mod_proxy_ajp and/or
      mod_proxy_balancer than deal with mod_jk across all the platforms
      I have to worry about (various UNIXes and Windows).

Also, yes, I know that I could enable status workers and have each 
Tomcat notify Apache that it is alive and present.  That's interesting, 
but adds end-administrator complexity in that Tomcat must be configured 
with an appropriate URL for Apache, access to the status worker must be 
protected via further configuration based on the hosts of the target 
Tomcats, Tomcat must know if it is being served via mod_proxy_ajp or the 
IIS/Tomcat connector, etc.  Further if Apache must be taken down it will 
lose track of which members are alive.  If other approaches truly seem 
untenable I can consider this further, but it currently does not seem as 
attractive.

Finally, if this should be addressed to the Apache dev list instead, 
please let me know.  I'm avoiding the temptation to cross-post here :-)

--
Jess Holle


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