httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Invitation to HTTPD commiters in tomcat-dev
Date Tue, 20 Jul 2004 15:13:52 GMT
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 

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".


View raw message