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.
Costin
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]