so the dynamic mapping is the solution, and it seems that's why
original jk developpers decided to handling JkMount by hand.
2005/10/30, Costin Manolache <[EMAIL PROTECTED]>:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
