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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > 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. <[EMAIL PROTECTED]> 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: [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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
