On 10/29/05, Henri Gomez <[EMAIL PROTECTED]> wrote:
> using AJP or HTTP or WHATEVERP protocol you want, the current need for
> me in my production systems is to be able to add / remove a tomcat
> machine to a LoadBalancing farm without having to restart the Apache 2
> web server.
Sounds like a very reasonable requirement. My point was that this is
not a requirement for the AJP protocol itself - but a requirement for
Apache and whatever modules are used in apache for load balancing and
forwarding.
How you interact with Apache to dynamically add machines ( and
generally - to configure it ) is yet another separate problem.
I think it is far better for anyone who has this requirement to
decouple the problems, and not try to mix wire protocol for forwarding
with the mechanism and protocol for management.
> A WEB admin (I work with them each days) would like to add / remove a
> tomcat dynamically, for example using an admin webapp on an
> 'load-balancing administrator console' running on a webapp hosted by
> a tomcat or may be even a pure Apache 2 application.
>
> If you told me it's impossible to add a REQUEST mapper (ie JkMount)
> dynamically to a running Apache 2.0, I say amen and we'll wait for
> HTTPD team to allow that.
AFAIK apache2 can do this with a restart, or with a module that does
dynamic mapping and has runtime reconfiguration support, like jk2 did.
>
> But something we could do allready is to add/remove a tomcat from a lb worker
> ?
Yes, it should be possible to do this - but I'm not sure what that has
to do with the AJP protocol.
You need some support in the apache module, and then a way to
interface with the module - eihter using a file + a signal or special
URL, etc, etc.
Costin
>
> 2005/10/25, Costin Manolache <[EMAIL PROTECTED]>:
> > On 10/25/05, Mladen Turk <[EMAIL PROTECTED]> wrote:
> > > Costin Manolache wrote:
> > > > DBUS is a good example in IMO - I'm not
> > > > saying to use their impl, which doesn't fit, just the protocol spec.
> > >
> > > The major power of AJP protocol is known-header-name indexing, and
> > > IMHO there is no other protocol that is HTTP application focused.
> >
> > Well, any protocol can do this - with the right message.
> >
> > In this case: it'll be:
> > enum knownHeadersCode={ .... }
> > and the message will have an array of ( knownHeaderCode, string ) and
> > then ( string string)
> >
> > Or some other variation - there is nothing so special in Ajp that
> > can't be encoded in a standard protocol. Except the fact that ajp is
> > not extensible - so it may save a few bytes.
> >
> >
> > > If there is really a need for a completely new protocol,
> > > and I doubt there is a real need for that right now, we must presume
> > > that the primary intent of the protocol is to allow communication of
> > > two well known and defined http applications.
> >
> > Sure - but this can be expressed as well on top of a more standard (
> > or common ) marshalling. Marshalling is not specific to any
> > application, not even in ajp ( maybe the stupid 'first chunk' - but
> > even this can be expressed with few extra bytes in a normal protocol
> > ).
> >
> > The API you expose - i.e. the message signatures - should remain
> > specific to the http
> > app. And a standard protocol would allow you to add all kind of extra
> > signatures.
> >
> >
> > > If you look at the XDR protocol, each 'string' type message is prefixed
> > > with additional two bytes compared with AJP, so beside that, the lack of
> > > header indexing would at least double the packet size, and downgrade the
> > > performance by twice.
> >
> > I don't think the 2 extra bytes is such a big problem.
> >
> > Actually there is one thing that is unique to AJP - the callbacks done
> > over the same connection, as responses ( since tomcat can't initiate a
> > call ). But even this can be expressed in a proper RPC - by having the
> > callback as a normal response.
> >
> > Costin
> >
> > ---------------------------------------------------------------------
> > 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]
