tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: Status/Authority of AJP/1.5
Date Tue, 25 Oct 2005 15:15:47 GMT
Henri, I can understand that a binary protocol is ( a bit ) faster
than plain http.

But what you describe is relatively light monitoring and management -
you won't do 1000 reconfigs per second.

There is absolutely no reason to extend the protocol with this - just
use a separate mechanism. Even in the complex world of Corba - the
discovery and configuration is not part of the core wire protocol, but
a separate API.

Just define whatever directory you like on top of JMX, with either JMX
or http interface - you could use JINI if you want, or zeroconfig/dns
or anything else. The only tricky part is Apache - but even there you
can do this kind of stuff in a separate module.

Security ( i.e. authentication ) might be the only reason to extend
AJP - but even this can be done on top of the existing protocol, using
a custom header and connection initiation.

AJP12 == binary HTTP.
Just tell me what you can't do using HTTP request/response mechanism.

Of course - I agree what you need is important, and it would be great
to have it - but
you would do it much faster and simpler if you don't touch ajp, but
work at jmx/servlet layer.

Costin

On 10/24/05, Henri Gomez <henri.gomez@gmail.com> wrote:
> AJP 1.5 should support automatic discovery of tomcat backend, new
> systems and new webapps.
>
> That's the current need for many of us when adding tomcats / webapp
> behind Apache 2 webservers. In such case we need to restart them and
> it's sad.
>
> How could it be accomplished, may be via a master tomcat who will give
> the tomcat farm topology to Apache HTTP2.
>
> What do you think ?
>
> 2005/10/25, Costin Manolache <costin@gmail.com>:
> > I see. Sorry, I've been sleeping for quite a while, I'm slowly getting
> > up to speed with the latest developments.
> >
> > Are you saying that mod_proxy_ajp is significantly faster than
> > mod_proxy ? That's interesting.
> >
> > To answer your question - ajp10 and ajp11 were used in JServ,
> > developed in Apache.
> > Ajp12 is based on 11, developed in the early days of tomcat. I think
> > jetty also suppors ( or supported ) the protocol at some time.
> >
> > IMHO - if a new version of the protocol is developed, there are 2 choices:
> > - preserve backwards compatibility - there are few ugly way to do this
> > - break backwards compatibility - in wich case it may be better to
> > redo the protocol so it is extensible, and maybe even better reuse an
> > existing protocol. An example to look at is the DBUS protocol ( from
> > freedesktop ) - or maybe classical RPC. Ad-hoc arbitrary binary
> > protocols can be a bad idea - as we see with ajp12 extensibility
> > problems.
> >
> >
> > Costin
> >
> > On 10/24/05, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
> > > Costin Manolache wrote:
> > > > I tought some time ago AJP was 'deprecated' - to be replaced with
> > > > plain HTTP and mod_proxy ?
> > >
> > > Why?
> > >
> > > It turns out that mod_proxy_ajp v.s. mod_proxy_http does prove the validity
> > > of optimizing the backend connection.  I don't think anyone forsees mod_jk
> > > being deprecated (at least, not insofar as it supports IIS/Netscape/Sun
> > > http servers), but from an Apache perspective, hopefully mod_proxy_ajp will
> > > make mod_jk/Apache a footnote in history :)
> > >
> > > Bill
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message