+1, that's what the original goal of AJP14, extending protocol from just requests forwarding to service/system messaging.
BTW, we should disable it by default on jk, to avoid problem with old tomcats release :) On Thu, 10 Feb 2005 11:02:22 +0100, Mladen Turk <[EMAIL PROTECTED]> wrote: > Henri Gomez wrote: > > Well we could provide the Tomcat load by many ways but I rather like > > keep them compatible with AJP13 : > > > > - Add a new message from jk to tomcat, like the CPING/CPONG, to get > > the expect load on tomcat. jk could decide to send this information > > packet each X requests. > > > > IMO those kind of things are OK for occasional info needed. > For AJP14 it will be used for topology discovery, and everything > related to dynamic configuration. > > > - Add a custom header in reply but this one should be decoded by jk in > > response and removed from browser response. > > > > Yes, all runtime data that are closely bound to per-request basis, > ie. have tendency to change frequently should be used with custom > headers (or on AJP14 with extra tags), and removed from the > pipeline of course. > Things like warnings of Tomcat going down, or not accepting any > new connections should be implemented in this fashion, because they > are instant messages. > Now that we have shared memory, the status will be visible across > all child processes. > > Regards, > Mladen. > > --------------------------------------------------------------------- > 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]
