Henri Gomez wrote:
>
> So next step should be to add LB functionalities (with sticky
> JSSESSION support) in mod_proxy => Graham ?
>
There is also a question of development cycle.
Are we gonna develop sending patches or what... Suggestions?
MT.
smime.p7s
Description: S/MIME cryptographi
gt;
Sent: Wednesday, July 21, 2004 9:27 AM
Subject: Re: Invitation to HTTPD commiters in tomcat-dev
Graham Leggett wrote:
> Mladen Turk wrote:
>
>> I don't think that it is necessary for a mod_ajp to be included inside
>> the
>> mod_proxy, although they are sharing
Henri Gomez wrote:
Graham Leggett wrote:
Costin Manolache wrote:
But I still think we should start with using mod_proxy with http
protocol, and add the missing load balancing and extra info - if we
are not happy with the performance and we need a small boost, we
could also add ajp.
I think this
Graham Leggett wrote:
Costin Manolache wrote:
But I still think we should start with using mod_proxy with http
protocol, and add the missing load balancing and extra info - if we
are not happy with the performance and we need a small boost, we could
also add ajp.
I think this is a good idea.
S
Costin Manolache wrote:
But I still think we should start with using mod_proxy with http
protocol, and add the missing load balancing and extra info - if we are
not happy with the performance and we need a small boost, we could also
add ajp.
I think this is a good idea.
Solve the general load ba
Graham Leggett wrote:
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside
the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It mak
Costin Manolache wrote:
One thing missing - the proposal to actually just use mod_proxy, with
enhancements for load balancing, and with http as protocol ( i.e. drop
Ajp ).
That would be a real simplification on both sides !
I also find HTTP to be more than adequate in most cases, but if there is
Mladen Turk wrote:
AjpBalancer could be applied to a theoretical proxy_balancer module (all
modules can define their own config parameters, even the helper modules,
the only guideline is that the config directives are named to give some
indication of the scope they're valid for, so instead of a
- Original Message -
From: "Mladen Turk" <[EMAIL PROTECTED]>
>I also see no reason why the mod_proxy functionally cannot be implemented in
>mod_jk2 :).
yes, but it is rocket science to actually get jk2 compiled and configured and to work
properly. mod_proxy is part of the core, and
takes
One thing missing - the proposal to actually just use mod_proxy, with
enhancements for load balancing, and with http as protocol ( i.e. drop
Ajp ).
That would be a real simplification on both sides !
The tiny performance benefit of a binary protocol is really not worth
it. The 'http parsing' pa
Graham Leggett wrote:
> > So, my question is. Why do we need again some container to
> accomplish that?
>
> Because the container already gives you an established
> configuration method, a standard set of documentation, and a
> standard expectation from end users on how it should work.
>
T
Mladen Turk wrote:
I think that we forked from jk/jk2 to be able to write from the scratch the
module that will do exactly _one_ and _only_one_ thing; and that is
effectively communicate with TC server using ajp13+ protocol.
So, my question is. Why do we need again some container to accomplish that
Henri Gomez wrote:
> >
> > Graham Leggett wrote:
> >
> >>Just rewriting mod_ajp for v2.0 isn't anything different to
> >>what exists now, so I don't see the point.
> >
> > Well, that's how you see it.
> > IMO trying again to squize the apache2->Tomcat module
> inside some already
> > presen
jean-frederic clere wrote:
I see in ap_proxy_http_handler() that DECLINED allows to try another. Is
there somewhere an example of a configuration using it?
ap_proxy_http_handler() is found in mod_proxy_http, which is the helper
module that handles the HTTP protocol in the proxy framework. You wil
Mladen Turk wrote:
Graham Leggett wrote:
I don't think that it is necessary for a mod_ajp to be
included inside
the mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts
ultimately makes for doing things in a consistent way. I
Mladen Turk wrote:
I think it's very necessary - sharing those common concepts
ultimately makes for doing things in a consistent way. It
makes a big difference to the usability of httpd.
I'm sure that the 'normalization' would lead to nowhere.
I don't follow - what does "normalisation would lead
Graham Leggett wrote:
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside
the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It mak
Graham Leggett wrote:
>
> > I don't think that it is necessary for a mod_ajp to be
> included inside
> > the mod_proxy, although they are sharing some common concepts.
>
> I think it's very necessary - sharing those common concepts
> ultimately makes for doing things in a consistent way. I
Henri Gomez wrote:
BTW, could we expect to be able to use in proxy_ajp URL like
ajp://VIRTUALNAME, where VIRTUALNAME could be the name of an
AJP cluster backend ?
That would be up to proxy_ajp to decide, so yes.
What happens is that when the config says
ProxyPass /myApp ajp://VIRTUALNAME
and the us
Graham Leggett wrote:
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside
the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It mak
Mladen Turk wrote:
I don't think that it is necessary for a mod_ajp to be included inside the
mod_proxy, although they are sharing some common concepts.
I think it's very necessary - sharing those common concepts ultimately
makes for doing things in a consistent way. It makes a big difference to
Mladen Turk wrote:
Graham Leggett wrote:
Thing is it's easier for end users to not have to mess around
with third party builds if it can possibly be avoided, and
it's the needs of the end users who are the most important,
not the developers.
It was the main reason why we tried to go beyond
Graham Leggett wrote:
>
> Thing is it's easier for end users to not have to mess around
> with third party builds if it can possibly be avoided, and
> it's the needs of the end users who are the most important,
> not the developers.
>
It was the main reason why we tried to go beyond the con
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 acc
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 <[EMAIL PROTECTED]> wrote:
Henri Gomez wrote:
> jk was designed a long time ago so may be mod_proxy allready support
> persistant connections.
Persistence
Henri Gomez wrote:
Now what about the mod_proxy load-balancing add-on ?
The thing I'm most happy about with the simple load balancing + sticky
session + failover is that the development would be short (hopefully),
be bundled with Apache quickly, and could really help people's
experience with Tom
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 rever
--- Begin Message ---
Henri Gomez wrote:
- mod_proxy + proxy_ajp could be one solution.
Now what about the mod_proxy load-balancing add-on ?
Would be a completely separate module.
The way proxy works, is that it:
- obtains the IP address to connect to (currently via DNS round robin,
but a module
Henri Gomez wrote:
Can we simplify this ?
Let's drop the word "worker" too :-)
The request is passed to a servlet container that may consist of one
or multiple instances.
Agreed, remove the old terms.
The proposal about mod_proxy + proxy_ajp could be something fine
isn't it.
And proxy_ajp could m
Henri Gomez wrote:
- mod_proxy + proxy_ajp could be one solution.
Now what about the mod_proxy load-balancing add-on ?
Would be a completely separate module.
The way proxy works, is that it:
- obtains the IP address to connect to (currently via DNS round robin,
but a module proxy_loadbalancer migh
Manni Wood wrote:
I asked you to develop your argument ;)
Ah. I'm trying my best. :-)
May be you could take a look as documentalist ?)
I would very happily volunteer my time to document this new module.
Where do I sign up? How do I gain acceptance as a documentor, and if I
am accepted, what woul
Costin Manolache wrote:
Henri Gomez wrote:
Graham Leggett wrote:
Henri Gomez wrote:
It's now time to refactor and redesign it with Apache 2.x (APR/AP) in
mind to follow Apache 2.x admins habbits and try to make something
simpler.
We came on httpd-dev for advice from experts, and may be an
extended
Graham Leggett wrote:
Henri Gomez wrote:
Well let see my suggestion :
ProxyPass /myWebapp/*.jsp ajp://myajpworker/
myajpworker is not a machine but a virtual resource which could be :
- a physical Tomcat using its AJP/1.3 connector
- a cluster of physical Tomcats using their AJP/1.3 connector
And v
Colm MacCarthaigh wrote:
On Tue, Jul 20, 2004 at 05:20:53PM +0200, Graham Leggett wrote:
The "httpd serves the static content" feature can be implemented through
extending ProxyPass to support regular expressions, for example:
ProxyPass /myWebapp/*.jsp http://tomcat/myWebapp/
RewriteCond %{REQUE
Henri Gomez wrote:
Graham Leggett wrote:
Henri Gomez wrote:
It's now time to refactor and redesign it with Apache 2.x (APR/AP) in
mind to follow Apache 2.x admins habbits and try to make something
simpler.
We came on httpd-dev for advice from experts, and may be an
extended mod_proxy could be the s
Henri Gomez wrote:
Well let see my suggestion :
ProxyPass /myWebapp/*.jsp ajp://myajpworker/
myajpworker is not a machine but a virtual resource which could be :
- a physical Tomcat using its AJP/1.3 connector
- a cluster of physical Tomcats using their AJP/1.3 connector
And via AJP/1.4 we could ma
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 h
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
t
--- Begin Message ---
Manni Wood wrote:
One of the things I thought AJP did that HTTP proxying to Tomcat could
not (but correct me here if I'm wrong) is let the servelt container know
whether or not the connection is HTTP vs. HTTPS. This sort of
information needs to get passed back to the servlet
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 t
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 p
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
Henri Gomez wrote:
Wayne Frazee wrote:
Please pardon me for attempting to marshall the obvious however what is
the advantage of AJP/1.x over HTTP?
- Persistant connections, mod_jk use a pool of socket connections
to avoid reopening connections between Apache and Tomcats.
You could set socket
Graham Leggett wrote:
Henri Gomez wrote:
It's now time to refactor and redesign it with Apache 2.x (APR/AP) in
mind to follow Apache 2.x admins habbits and try to make something
simpler.
We came on httpd-dev for advice from experts, and may be an
extended mod_proxy could be the solution. But we als
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
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 h
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 h
Graham Leggett wrote:
Henri Gomez wrote:
It's now time to refactor and redesign it with Apache 2.x (APR/AP) in
mind to follow Apache 2.x admins habbits and try to make something
simpler.
We came on httpd-dev for advice from experts, and may be an
extended mod_proxy could be the solution. But we als
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
Wayne Frazee wrote:
Please pardon me for attempting to marshall the obvious however what is
the advantage of AJP/1.x over HTTP?
- Persistant connections, mod_jk use a pool of socket connections
to avoid reopening connections between Apache and Tomcats.
You could set socket timeout to make the
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
Henri Gomez wrote:
It's now time to refactor and redesign it with Apache 2.x (APR/AP) in
mind to follow Apache 2.x admins habbits and try to make something
simpler.
We came on httpd-dev for advice from experts, and may be an
extended mod_proxy could be the solution. But we also want to keep
the AJP
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:
He
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 fr
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
Manni Wood wrote:
I very rarely post to this list, but I've been building web sites for
over eight years, and want to chime in.
In my experience building web sites for Fortune 500 companies (some of
them Fortune 50 companies), the "get Apache to serve static content
while Tomcat only takes care of
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 f
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
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 fea
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
60 matches
Mail list logo
