tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Invitation to HTTPD commiters in tomcat-dev
Date Tue, 20 Jul 2004 15:18:39 GMT
Well, the mod_proxy + enhancements for sticky session + enhancements for 
passing auth info sounds reasonable - and if nobody wants the JMX 
support, then maybe we won't need to write a new connector anyway :-)

Remy will be happy - we'll only use the http connector.


Graham Leggett wrote:

> Henri Gomez wrote:
>> jk was designed a long time ago so may be mod_proxy allready support
>> persistant connections.
> Persistence will happen on the backend on the condition there was 
> persistence on the frontend. Generally the networks between backend and 
> frontend are fast enough that connection setup is not a problem - a 
> bigger problem is having expensive backend processes hanging around 
> attached to a persistent connection that is not being used (assuming 
> these connections are held by a tomcat thread of course, which may or 
> may not be the case, not sure how tomcat is built internally).
>> Great. And if you handle in the proxy_loadbalancing.c
>> the JSESSION_ID, (sticky session) to map next requests
>> to the tomcat who set it, you'll have everything needed.
> Sticky sessions has been on my list of things to support for ages - 
> perhaps a "proxy_sticky.c" module could take a single parameter (the 
> name of the parameter and/or cookie) and keep track of which server 
> served it.
> If you had redundant frontends you might have a mechanism to keep track 
> of which server is handling which session stored in a shared mechanism.
> A separate module might keep track of which tomcat servers are up or 
> down, removing a server from the list of available servers on certain 
> events (connection refused, error 4xx, 5xx, whatever).
>> Well LDAP could be use for configuration outside a file. JMX/CMX goes a
>> bit farther since it let you update some characteristics at runtime.
>> But I agree that providing a JMX/CMX facade to Apache 2.x modules will
>> be a good starting point. Costin will certainly clarify this point with
>> you.
>> In fine the discussed mod_ajp module should detect topology change in a
>> second phase to learn for example that a tomcat in a cluster 
>> started/stopped a web application, so next requests could be redirected
>> to another tomcat in the cluster. Also you should be able to update the
>> load factor for each tomcat, may be having a load factor by 
>> Webapplication.
> In theory this kind of thing should not be limited to tomcat only, but 
> to web applications (whether PHP, whatever) in general.
> Perhaps a mechanism that allows the backend to connect to the frontend 
> and say "status has changed, I am offering webapp XXX now, so count me 
> into the pool". Or a mechanism for the frontend to poll the 
> characteristics of the backend so that it can autolearn what webapp can 
> be found where (has the advantage of not requiring a special backend 
> module, apart from a magic URL on the backend giving relevant the 
> information)
> This opens up some interesting possiblities for "virtual mappings". 
> Something like this:
> ProxyPass /myWebapp virtual://myWebbapp (or something)
> Where proxy can hand out the request to a backend that has recently said 
> "hi proxy, I serve myWebapp, feel free to contact me to fulfil a request".
> Regards,
> Graham
> -- 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message