although I'm not a commiter, I like to add 2 cents to the discussion.
I like the idea of supporting JMX and the capbility of deploying a
webapp without restarting the server. From the discussions so far, the
task isn't simple, and may not fit the majority of users.

if 80% of the users don't have this need, justifying the extra
features and possibly added complexity is debatable. Would it be
sufficient to create a hook for more advanced mods?  There are people
using tomcat's admin tool to deploy/redeploy webapps, so having the
feature in mod_proxy or whatever would make the edge cases less
painful.

using JMX would make managing a cluster of servers easier and reduce
the need to login to every single server to stop, edit conf files, and
restart.

peter


On Tue, 20 Jul 2004 08:18:39 -0700, Costin Manolache
<[EMAIL PROTECTED]> wrote:
> 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]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to