You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Henri Gomez <hg...@apache.org> on 2004/07/20 11:24:28 UTC
Invitation to HTTPD commiters in tomcat-dev
We're discussing on tomcat-dev about a new Apache to Tomcat
Apache 2.x module.
We'd like to see some of the core HTTPD developpers joins
the discussion about the post JK/JK2 module.
The goal of this new module :
- 100% Apache 2.x module
- Easy integration with existing Apache 2.x modules
and directives, Location, Alias, Directory, Files, SetEnvIf...
- Configuration done ONLY in httpd.conf to follow the usual
Apache 2.x habbits.
Well we need your precious expertise in this discussion.
Regards
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Jul 20, 2004 at 06:02:37PM +0100, Colm MacCarthaigh wrote:
> Using OPTIONS has the advantage of being backwards compatible, if you
> send OPTIONS to a plain-old HTTP receiver, the standard ACK can be
> taken to mean "yep, I'm here". Intelligent backends (read: modify
> tomcat and co slightly) can have an X-header or whatever to go
> "I'm accepting this, this and this, and my current load is this".
Oh and I forgot to mention, it can be server-wide or URI-specific,
which seems like desirable flexibility in this situation.
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Colm MacCarthaigh wrote:
> Using OPTIONS has the advantage of being backwards compatible, if you
> send OPTIONS to a plain-old HTTP receiver, the standard ACK can be
> taken to mean "yep, I'm here". Intelligent backends (read: modify
> tomcat and co slightly) can have an X-header or whatever to go
> "I'm accepting this, this and this, and my current load is this".
This makes sense - you would just need to tell proxy the possible
servers, and an intelligent load balancer might try find out the current
status of those servers based on querying options to find out on a
regular basis.
Regards,
Graham
--
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Colm MacCarthaigh wrote:
> Using OPTIONS has the advantage of being backwards compatible, if you
> send OPTIONS to a plain-old HTTP receiver, the standard ACK can be
> taken to mean "yep, I'm here". Intelligent backends (read: modify
> tomcat and co slightly) can have an X-header or whatever to go
> "I'm accepting this, this and this, and my current load is this".
This makes sense - you would just need to tell proxy the possible
servers, and an intelligent load balancer might try find out the current
status of those servers based on querying options to find out on a
regular basis.
Regards,
Graham
--
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Colm MacCarthaigh <co...@stdlib.net>.
On Tue, Jul 20, 2004 at 05:13:52PM +0200, Graham Leggett wrote:
> 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)
Rather than a magic URL, this sounds like a job for OPTIONS. The clever
load balancing code could send an OPTIONS request and use the response
to determine if that particular backend is a) up b) accepting requests
at all c) associate a priority with that backend.
Using OPTIONS has the advantage of being backwards compatible, if you
send OPTIONS to a plain-old HTTP receiver, the standard ACK can be
taken to mean "yep, I'm here". Intelligent backends (read: modify
tomcat and co slightly) can have an X-header or whatever to go
"I'm accepting this, this and this, and my current load is this".
>From RFC2616:
"This method allows the client to determine the options and/or
requirements associated with a resource, or the capabilities of a
server, without implying a resource action or initiating a resource
retrieval."
> 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".
Same here, but wouldn't be elegant to use OPTIONS?
--
Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by ARhermitgirl <ar...@yahoo.com>.
TAKE ME OFF THIS MAILING LIST IMMEDIATELY... I DID NOT REQUEST THIS AND I DO NOT WANT ANOTHER EMAIL FROM JAKARTA.APACHE.ORG
Graham Leggett <mi...@sharp.fm> 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
--
> ATTACHMENT part 2 application/x-pkcs7-signature name=smime.p7s
---------------------------------
Do you Yahoo!?
Vote for the stars of Yahoo!'s next ad campaign!
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
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
--
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
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
--
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Jess Holle wrote:
>
>> One issue here:
>>
>> When Apache and Tomcat are used together via AJP13:
>>
>> 1. The host, port, protocol, etc, are exactly that at the Apache
>> level, i.e. one's web app sees Apache and Tomcat as 1
>> entity. This is a very good thing overall compared to reverse
>> proxying (if
>> that's the mod_proxy proposal).
>
> I have no idea how to get around that ;) This seems a showstopper: the
> user will have to read the connector's documentation.
Certainly things function in a reverse proxy environment and so the more
complex situation is handled. The issue is that individual developers
*can* do bad things by assuming that the request protocol is that they
should use in <base> tags, etc.
Overall, that would just be life, though and is insufficient reason not
to leverage mod_proxy.
>> 2. The body content, query string, etc, are reported to one's web
>> application precisely as sent, whereas Tomcat pre-processes them a
>> bit more than picky, low-level request parsing code can accept.
>> [Yes, the "picky" code is *too* picky, but it isn't mine :-)]
>
> I have no idea what your webapp is doing, but it's not portable. All
> the trasformations done respect the HTTP and servlet specifications.
Actually it is rather portable and does not break any spec to the best
of my knowledge. It just assumes it can get at the original content
body stream, request string, etc, as an alternative to getParameter()
without missing anything. Why this is the case is a long story. I also
miss forget exactly where things fall down, but Apache, iPlanet (with
embedded servlet engine), and IIS (with Tomcat) all work (except config
issues with IIS 6...)
This appears to be far removed from most folks' experience, so I guess
Tomcat's httpd is good enough for most.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Jess Holle wrote:
> One issue here:
>
> When Apache and Tomcat are used together via AJP13:
>
> 1. The host, port, protocol, etc, are exactly that at the Apache
> level, i.e. one's web app sees Apache and Tomcat as 1 entity.
> This is a very good thing overall compared to reverse proxying (if
> that's the mod_proxy proposal).
I have no idea how to get around that ;) This seems a showstopper: the
user will have to read the connector's documentation.
> 2. The body content, query string, etc, are reported to one's web
> application precisely as sent, whereas Tomcat pre-processes them a
> bit more than picky, low-level request parsing code can accept.
> [Yes, the "picky" code is *too* picky, but it isn't mine :-)]
I have no idea what your webapp is doing, but it's not portable. All the
trasformations done respect the HTTP and servlet specifications.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Jess Holle <je...@ptc.com>.
Remy Maucherat wrote:
> Costin Manolache 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.
>
> I think AJP has advantages, but if the HTTPd folks only accept a
> simple solution based on mod_proxy, then so be it, it'll be our entry
> level connector.
One issue here:
When Apache and Tomcat are used together via AJP13:
1. The host, port, protocol, etc, are exactly that at the Apache
level, i.e. one's web app sees Apache and Tomcat as 1 entity.
This is a very good thing overall compared to reverse proxying (if
that's the mod_proxy proposal).
2. The body content, query string, etc, are reported to one's web
application precisely as sent, whereas Tomcat pre-processes them a
bit more than picky, low-level request parsing code can accept.
[Yes, the "picky" code is *too* picky, but it isn't mine :-)]
--
Jess Holle
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache 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.
>
>
> I think AJP has advantages, but if the HTTPd folks only accept a simple
> solution based on mod_proxy, then so be it, it'll be our entry level
> connector.
AJP is an RPC protocol - the "binary encoding of http headers" doesn't
buy us too much ( with coyote httpd ). Session stickiness is easy to add
to mod_proxy, and I assume passing auth info is also possible.
If we only want to use ajp for forwarding - no back channel for config -
then there is no point in using RPC and binary protocol.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Remy Maucherat wrote:
> I think AJP has advantages, but if the HTTPd folks only accept a simple
> solution based on mod_proxy, then so be it, it'll be our entry level
> connector.
We'll certainly be interested in features like load balancing, sticky
sessions, stuff like that - but the general design philosophy is that
the functionality should be general enough to be used as widely as possible.
Regards,
Graham
--
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Costin Manolache 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.
>
>
> I think AJP has advantages, but if the HTTPd folks only accept a simple
> solution based on mod_proxy, then so be it, it'll be our entry level
> connector.
The discussion is still open :)
BTW, we could imagine that even AJP/1.4 topology update could came
from HTTP/1.1
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache 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.
I think AJP has advantages, but if the HTTPd folks only accept a simple
solution based on mod_proxy, then so be it, it'll be our entry level
connector.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Peter Lin <wo...@gmail.com>.
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
<cm...@yahoo.com> 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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Costin Manolache <cm...@yahoo.com>.
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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Graham Leggett wrote:
> Henri Gomez wrote:
>
>> And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
>
>
> In all my deployments of tomcat I have never seen the point of a custom
> protocol that did exactly what HTTP does, so all my tomcat deployments
> are all HTTP, with a simple mod_proxy frontend.
Well AJP/1.3 save cycle in tomcat avoiding it to re-decode headers for
examples. It forward also the SSL infos if needed. And AJP/1.3 use
persistant connections so it safe cycle also.
jk was designed a long time ago so may be mod_proxy allready support
persistant connections.
> Even the "get Apache to server static content" feature wasn't enough of
> a drawcard, as proper HTTP cache handling and a suitable cache solved
> this problem. It was far more important for me to arrange the web
> application as a self contained unit - I would rather be more tidy with
> an install at the expense of a slightly higher load, than sacrifice a
> clean install to save some cycles.
>
>> - If you add load-balancing/fault-tolerance and AJP 1.3 support in
>> mod_proxy you'll have about 99% of the current functionalities of
>> jk 1.2.x.
>>
>> We discussed also the need for some dynamic mapping and topology
>> discovery/update (between Apache and Tomcats Clusters).
>
>
> Proxy has a placeholder in it that says "put the code to make decision
> about load balancing etc here" - all that is needed is a hook and a
> module "proxy_loadbalancing.c" to make it happen.
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.
Of course you should also handle some mixed cases, like full
round-robin, and sticky round-robin.
The idea is interesting.
>> And in fine, we like to have some JMX like functionnalities in Apache 2,
>> in our case CMX for C Management Extension, a way to update Apache 2.x
>> configuration while the server is running...
>
>
> This is possibly a whole separate project in itself.
>
> I have been meaning to work on a get-apache-config-out-of-ldap extension
> for a while, what it really should be is "get apache config out of
> wherever", but this should be an Apache wide thing, not limited to a
> single module or technology.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Jess Holle <je...@ptc.com>.
Costin Manolache wrote:
> Graham Leggett wrote:
>
>> In all my deployments of tomcat I have never seen the point of a
>> custom protocol that did exactly what HTTP does, so all my tomcat
>> deployments are all HTTP, with a simple mod_proxy frontend.
>>
>> Even the "get Apache to server static content" feature wasn't enough
>> of a drawcard, as proper HTTP cache handling and a suitable cache
>> solved this problem. It was far more important for me to arrange the
>> web application as a self contained unit - I would rather be more
>> tidy with an install at the expense of a slightly higher load, than
>> sacrifice a clean install to save some cycles.
>
> There is a bit more - we want to be able to have Apache authenticate
> and pass this info to tomcat for example. I don't know if this can be
> done with mod_proxy ( maybe have it add an extra header - but that may
> have security problems ).
That is a hard requirement for us as well.
>>> And in fine, we like to have some JMX like functionnalities in
>>> Apache 2,
>>> in our case MX for C Management Extension, a way to update Apache 2.x
>>> configuration while the server is running...
>>
>> This is possibly a whole separate project in itself.
>
Agreed. It sounds like a great project, but a *separate* project and
module.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Costin Manolache <cm...@yahoo.com>.
Graham Leggett wrote:
> In all my deployments of tomcat I have never seen the point of a custom
> protocol that did exactly what HTTP does, so all my tomcat deployments
> are all HTTP, with a simple mod_proxy frontend.
>
> Even the "get Apache to server static content" feature wasn't enough of
> a drawcard, as proper HTTP cache handling and a suitable cache solved
> this problem. It was far more important for me to arrange the web
> application as a self contained unit - I would rather be more tidy with
> an install at the expense of a slightly higher load, than sacrifice a
> clean install to save some cycles.
There is a bit more - we want to be able to have Apache authenticate and
pass this info to tomcat for example. I don't know if this can be done
with mod_proxy ( maybe have it add an extra header - but that may have
security problems ).
>> And in fine, we like to have some JMX like functionnalities in Apache 2,
>> in our case MX for C Management Extension, a way to update Apache 2.x
>> configuration while the server is running...
>
>
> This is possibly a whole separate project in itself.
>
> I have been meaning to work on a get-apache-config-out-of-ldap extension
> for a while, what it really should be is "get apache config out of
> wherever", but this should be an Apache wide thing, not limited to a
> single module or technology.
The actual problem is how to push config changes without restarting the
server. Some changes obviously require restart, but chaning mappings for
example should be dynamic.
In MPM multithreaded mode some modules may cache session information -
frequent restarts are going to be more difficult than with single
threaded server.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Costin Manolache <cm...@yahoo.com>.
I agree here, it is an excelent idea.
If we want to keep it to a minimum - no multi-protocol, no jmx, no
multiple servers - then making enhancements to mod_proxy and using http
is much better than a mod_ajp.
Tomcat httpd is fast enough, and all mod_proxy enhancements for load
balancing could be used for more than tomcat.
Costin
Remy Maucherat wrote:
> I think using mod_proxy is acceptable for our most important needs, as
> the Tomcat HTTP/1.1 connnector has acceptable performance.
>
> We would need:
> - JSESSIONID stickiness
> - persistent connections support
> - (and of course) load balancing (with a static worker list) with failover
> - bonus points for auto retry (if the request allows it) to another node
> when recieving a 503 status
>
> SSL client-cert support (which I have no idea how to implement with
> mod_proxy, or maybe I missed something) and more generally, support for
> doing auth on the native webserver doesn't seem to be there, which is a
> problem.
>
> For ease of use, we need this "Tomcat" policy (actually, it's not Tomcat
> specific, obviously) to be included in the Apache source distribution,
> and ready to enable.
>
> I would like a more custom solution better, but if that's the only
> acceptable solution for you (and you accept the module into the Apache
> ;) ), then I'm ok with it.
>
> In this case, we would need another, more complex connector for the
> advanced use cases, but we would have addressed the needs of the
> majority of users.
>
> Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Graham Leggett wrote:
> Henri Gomez wrote:
>
>> And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
>
> In all my deployments of tomcat I have never seen the point of a custom
> protocol that did exactly what HTTP does, so all my tomcat deployments
> are all HTTP, with a simple mod_proxy frontend.
>
> Even the "get Apache to server static content" feature wasn't enough of
> a drawcard, as proper HTTP cache handling and a suitable cache solved
> this problem. It was far more important for me to arrange the web
> application as a self contained unit - I would rather be more tidy with
> an install at the expense of a slightly higher load, than sacrifice a
> clean install to save some cycles.
>
>> - If you add load-balancing/fault-tolerance and AJP 1.3 support in
>> mod_proxy you'll have about 99% of the current functionalities of
>> jk 1.2.x.
>>
>> We discussed also the need for some dynamic mapping and topology
>> discovery/update (between Apache and Tomcats Clusters).
>
> Proxy has a placeholder in it that says "put the code to make decision
> about load balancing etc here" - all that is needed is a hook and a
> module "proxy_loadbalancing.c" to make it happen.
>
>> And in fine, we like to have some JMX like functionnalities in Apache 2,
>> in our case CMX for C Management Extension, a way to update Apache 2.x
>> configuration while the server is running...
>
> This is possibly a whole separate project in itself.
>
> I have been meaning to work on a get-apache-config-out-of-ldap extension
> for a while, what it really should be is "get apache config out of
> wherever", but this should be an Apache wide thing, not limited to a
> single module or technology.
I think using mod_proxy is acceptable for our most important needs, as
the Tomcat HTTP/1.1 connnector has acceptable performance.
We would need:
- JSESSIONID stickiness
- persistent connections support
- (and of course) load balancing (with a static worker list) with failover
- bonus points for auto retry (if the request allows it) to another node
when recieving a 503 status
SSL client-cert support (which I have no idea how to implement with
mod_proxy, or maybe I missed something) and more generally, support for
doing auth on the native webserver doesn't seem to be there, which is a
problem.
For ease of use, we need this "Tomcat" policy (actually, it's not Tomcat
specific, obviously) to be included in the Apache source distribution,
and ready to enable.
I would like a more custom solution better, but if that's the only
acceptable solution for you (and you accept the module into the Apache
;) ), then I'm ok with it.
In this case, we would need another, more complex connector for the
advanced use cases, but we would have addressed the needs of the
majority of users.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Graham Leggett wrote:
> Henri Gomez wrote:
>
>> And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
>
>
> In all my deployments of tomcat I have never seen the point of a custom
> protocol that did exactly what HTTP does, so all my tomcat deployments
> are all HTTP, with a simple mod_proxy frontend.
Well AJP/1.3 save cycle in tomcat avoiding it to re-decode headers for
examples. It forward also the SSL infos if needed. And AJP/1.3 use
persistant connections so it safe cycle also.
jk was designed a long time ago so may be mod_proxy allready support
persistant connections.
> Even the "get Apache to server static content" feature wasn't enough of
> a drawcard, as proper HTTP cache handling and a suitable cache solved
> this problem. It was far more important for me to arrange the web
> application as a self contained unit - I would rather be more tidy with
> an install at the expense of a slightly higher load, than sacrifice a
> clean install to save some cycles.
>
>> - If you add load-balancing/fault-tolerance and AJP 1.3 support in
>> mod_proxy you'll have about 99% of the current functionalities of
>> jk 1.2.x.
>>
>> We discussed also the need for some dynamic mapping and topology
>> discovery/update (between Apache and Tomcats Clusters).
>
>
> Proxy has a placeholder in it that says "put the code to make decision
> about load balancing etc here" - all that is needed is a hook and a
> module "proxy_loadbalancing.c" to make it happen.
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.
Of course you should also handle some mixed cases, like full
round-robin, and sticky round-robin.
The idea is interesting.
>> And in fine, we like to have some JMX like functionnalities in Apache 2,
>> in our case CMX for C Management Extension, a way to update Apache 2.x
>> configuration while the server is running...
>
>
> This is possibly a whole separate project in itself.
>
> I have been meaning to work on a get-apache-config-out-of-ldap extension
> for a while, what it really should be is "get apache config out of
> wherever", but this should be an Apache wide thing, not limited to a
> single module or technology.
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.
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Remy Maucherat <re...@apache.org>.
Graham Leggett wrote:
> Henri Gomez wrote:
>
>> And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
>
> In all my deployments of tomcat I have never seen the point of a custom
> protocol that did exactly what HTTP does, so all my tomcat deployments
> are all HTTP, with a simple mod_proxy frontend.
>
> Even the "get Apache to server static content" feature wasn't enough of
> a drawcard, as proper HTTP cache handling and a suitable cache solved
> this problem. It was far more important for me to arrange the web
> application as a self contained unit - I would rather be more tidy with
> an install at the expense of a slightly higher load, than sacrifice a
> clean install to save some cycles.
>
>> - If you add load-balancing/fault-tolerance and AJP 1.3 support in
>> mod_proxy you'll have about 99% of the current functionalities of
>> jk 1.2.x.
>>
>> We discussed also the need for some dynamic mapping and topology
>> discovery/update (between Apache and Tomcats Clusters).
>
> Proxy has a placeholder in it that says "put the code to make decision
> about load balancing etc here" - all that is needed is a hook and a
> module "proxy_loadbalancing.c" to make it happen.
>
>> And in fine, we like to have some JMX like functionnalities in Apache 2,
>> in our case CMX for C Management Extension, a way to update Apache 2.x
>> configuration while the server is running...
>
> This is possibly a whole separate project in itself.
>
> I have been meaning to work on a get-apache-config-out-of-ldap extension
> for a while, what it really should be is "get apache config out of
> wherever", but this should be an Apache wide thing, not limited to a
> single module or technology.
I think using mod_proxy is acceptable for our most important needs, as
the Tomcat HTTP/1.1 connnector has acceptable performance.
We would need:
- JSESSIONID stickiness
- persistent connections support
- (and of course) load balancing (with a static worker list) with failover
- bonus points for auto retry (if the request allows it) to another node
when recieving a 503 status
SSL client-cert support (which I have no idea how to implement with
mod_proxy, or maybe I missed something) and more generally, support for
doing auth on the native webserver doesn't seem to be there, which is a
problem.
For ease of use, we need this "Tomcat" policy (actually, it's not Tomcat
specific, obviously) to be included in the Apache source distribution,
and ready to enable.
I would like a more custom solution better, but if that's the only
acceptable solution for you (and you accept the module into the Apache
;) ), then I'm ok with it.
In this case, we would need another, more complex connector for the
advanced use cases, but we would have addressed the needs of the
majority of users.
Rémy
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Henri Gomez wrote:
> And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
In all my deployments of tomcat I have never seen the point of a custom
protocol that did exactly what HTTP does, so all my tomcat deployments
are all HTTP, with a simple mod_proxy frontend.
Even the "get Apache to server static content" feature wasn't enough of
a drawcard, as proper HTTP cache handling and a suitable cache solved
this problem. It was far more important for me to arrange the web
application as a self contained unit - I would rather be more tidy with
an install at the expense of a slightly higher load, than sacrifice a
clean install to save some cycles.
> - If you add load-balancing/fault-tolerance and AJP 1.3 support in
> mod_proxy you'll have about 99% of the current functionalities of
> jk 1.2.x.
>
> We discussed also the need for some dynamic mapping and topology
> discovery/update (between Apache and Tomcats Clusters).
Proxy has a placeholder in it that says "put the code to make decision
about load balancing etc here" - all that is needed is a hook and a
module "proxy_loadbalancing.c" to make it happen.
> And in fine, we like to have some JMX like functionnalities in Apache 2,
> in our case CMX for C Management Extension, a way to update Apache 2.x
> configuration while the server is running...
This is possibly a whole separate project in itself.
I have been meaning to work on a get-apache-config-out-of-ldap extension
for a while, what it really should be is "get apache config out of
wherever", but this should be an Apache wide thing, not limited to a
single module or technology.
Regards,
Graham
--
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Graham Leggett <mi...@sharp.fm>.
Henri Gomez wrote:
> And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
In all my deployments of tomcat I have never seen the point of a custom
protocol that did exactly what HTTP does, so all my tomcat deployments
are all HTTP, with a simple mod_proxy frontend.
Even the "get Apache to server static content" feature wasn't enough of
a drawcard, as proper HTTP cache handling and a suitable cache solved
this problem. It was far more important for me to arrange the web
application as a self contained unit - I would rather be more tidy with
an install at the expense of a slightly higher load, than sacrifice a
clean install to save some cycles.
> - If you add load-balancing/fault-tolerance and AJP 1.3 support in
> mod_proxy you'll have about 99% of the current functionalities of
> jk 1.2.x.
>
> We discussed also the need for some dynamic mapping and topology
> discovery/update (between Apache and Tomcats Clusters).
Proxy has a placeholder in it that says "put the code to make decision
about load balancing etc here" - all that is needed is a hook and a
module "proxy_loadbalancing.c" to make it happen.
> And in fine, we like to have some JMX like functionnalities in Apache 2,
> in our case CMX for C Management Extension, a way to update Apache 2.x
> configuration while the server is running...
This is possibly a whole separate project in itself.
I have been meaning to work on a get-apache-config-out-of-ldap extension
for a while, what it really should be is "get apache config out of
wherever", but this should be an Apache wide thing, not limited to a
single module or technology.
Regards,
Graham
--
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Nick Kew wrote:
> On Tue, 20 Jul 2004, Henri Gomez wrote:
>
> [ chopped tomcat-dev because that bounces my mail ]
>
>
>>>As a startingpoint, how about telling us what tomcat needs that
>>>mod_proxy and friends don't provide?
>>
>>In mod_jk/jk2, there is support for load-balancing and fault-tolerance
>>and it's a key feature.
>
>
> Good start.
>
> I'm guessing you're ahead of me here, and your reason for posting to
> dev@httpd is that you can see that implementing these capabilities
> will be of general interest to more than just tomcat users?
Back to tomcat-dev + httpd-dev.
Well this kind of features will be usefull for more than just
Tomcat users of course.
Our main interest in inviting httpd-dev members to tomcat-dev list
is to see if common interest could be shared and of course take
recommandations for the jk/jk2 successor.
>
> My gut feeling would be to keep this properly modular. Let mod_proxy
> be the core of it, and implement load-balancing and fault-tolerance
> in additional modules. As a matter of fact, one of my wishlist-projects
> is a connection-pooling module for backend HTTP connections in a proxy.
> That might actually be the same as your project.
And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
In fact mod_proxy could be a good starting point for learning how
relying request from Apache 2.x to Tomcat for what we called
actually mod_ajp, to avoid confusion with jk/jk2.
But :
- If you add load-balancing/fault-tolerance and AJP 1.3 support in
mod_proxy you'll have about 99% of the current functionalities of
jk 1.2.x.
We discussed also the need for some dynamic mapping and topology
discovery/update (between Apache and Tomcats Clusters).
And in fine, we like to have some JMX like functionnalities in Apache 2,
in our case CMX for C Management Extension, a way to update Apache 2.x
configuration while the server is running...
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Nick Kew wrote:
> On Tue, 20 Jul 2004, Henri Gomez wrote:
>
> [ chopped tomcat-dev because that bounces my mail ]
>
>
>>>As a startingpoint, how about telling us what tomcat needs that
>>>mod_proxy and friends don't provide?
>>
>>In mod_jk/jk2, there is support for load-balancing and fault-tolerance
>>and it's a key feature.
>
>
> Good start.
>
> I'm guessing you're ahead of me here, and your reason for posting to
> dev@httpd is that you can see that implementing these capabilities
> will be of general interest to more than just tomcat users?
Back to tomcat-dev + httpd-dev.
Well this kind of features will be usefull for more than just
Tomcat users of course.
Our main interest in inviting httpd-dev members to tomcat-dev list
is to see if common interest could be shared and of course take
recommandations for the jk/jk2 successor.
>
> My gut feeling would be to keep this properly modular. Let mod_proxy
> be the core of it, and implement load-balancing and fault-tolerance
> in additional modules. As a matter of fact, one of my wishlist-projects
> is a connection-pooling module for backend HTTP connections in a proxy.
> That might actually be the same as your project.
And what about using AJP/1.3 instead of HTTP for connection to tomcat ?)
In fact mod_proxy could be a good starting point for learning how
relying request from Apache 2.x to Tomcat for what we called
actually mod_ajp, to avoid confusion with jk/jk2.
But :
- If you add load-balancing/fault-tolerance and AJP 1.3 support in
mod_proxy you'll have about 99% of the current functionalities of
jk 1.2.x.
We discussed also the need for some dynamic mapping and topology
discovery/update (between Apache and Tomcats Clusters).
And in fine, we like to have some JMX like functionnalities in Apache 2,
in our case CMX for C Management Extension, a way to update Apache 2.x
configuration while the server is running...
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 20 Jul 2004, Henri Gomez wrote:
[ chopped tomcat-dev because that bounces my mail ]
> > As a startingpoint, how about telling us what tomcat needs that
> > mod_proxy and friends don't provide?
>
> In mod_jk/jk2, there is support for load-balancing and fault-tolerance
> and it's a key feature.
Good start.
I'm guessing you're ahead of me here, and your reason for posting to
dev@httpd is that you can see that implementing these capabilities
will be of general interest to more than just tomcat users?
My gut feeling would be to keep this properly modular. Let mod_proxy
be the core of it, and implement load-balancing and fault-tolerance
in additional modules. As a matter of fact, one of my wishlist-projects
is a connection-pooling module for backend HTTP connections in a proxy.
That might actually be the same as your project.
--
Nick Kew
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Nick Kew wrote:
> On Tue, 20 Jul 2004, Henri Gomez wrote:
>
>
>>We're discussing on tomcat-dev about a new Apache to Tomcat
>>Apache 2.x module.
>>
>>We'd like to see some of the core HTTPD developpers joins
>>the discussion about the post JK/JK2 module.
>
>
> As a startingpoint, how about telling us what tomcat needs that
> mod_proxy and friends don't provide?
In mod_jk/jk2, there is support for load-balancing and fault-tolerance
and it's a key feature.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Henri Gomez <hg...@apache.org>.
Nick Kew wrote:
> On Tue, 20 Jul 2004, Henri Gomez wrote:
>
>
>>We're discussing on tomcat-dev about a new Apache to Tomcat
>>Apache 2.x module.
>>
>>We'd like to see some of the core HTTPD developpers joins
>>the discussion about the post JK/JK2 module.
>
>
> As a startingpoint, how about telling us what tomcat needs that
> mod_proxy and friends don't provide?
In mod_jk/jk2, there is support for load-balancing and fault-tolerance
and it's a key feature.
Re: Invitation to HTTPD commiters in tomcat-dev
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 20 Jul 2004, Henri Gomez wrote:
> We're discussing on tomcat-dev about a new Apache to Tomcat
> Apache 2.x module.
>
> We'd like to see some of the core HTTPD developpers joins
> the discussion about the post JK/JK2 module.
As a startingpoint, how about telling us what tomcat needs that
mod_proxy and friends don't provide?
--
Nick Kew