Henri Gomez wrote:
Mladen Turk wrote:
The AJP13 protocol will have to be enhanced (or better enabled) to use the
'Service channel' and 'Data Filter'. It is not necessary to define all
Service channel modes like server topology, or server readiness, neither to
define all the Data Filter modes like cryptography or compression. I was
thinking of something like 'extensions' to the protocol, meaning that one
can extend the protocol to some desired level.
Yes.
My initial idea for AJP/1.4 wass to mix on the same wire request forwaring which is the core functionnality of AJP/1.3 with system messaging.
- Service channel is a channel to send/received update between Apache and Tomcats :
- Negociation between Apache and Tomcat.
* Should we use an authentification scheme between Apache and Tomcat (ajp1.3 make that Tomcat trust any Web server caming via AJP13).
* Should we compress the requests/replies
* Should we crypt the requests/replies.
- Web Applications state updates :
* a Web Application is added
* a Web Application is removed
- Updates in cluster configurations :
* worker1 was handling 25% of total load, now it could handle 35%.
* worker2 in cluster is down for maintenance....
* Apache 2 could use worker3 for this cluster, it could reach it at IP/PORT....
Ideally since we could have a cluster of Apache WebServer linked to a cluster of Tomcat ServletEngines, and that member could enter or exit
these 2 clusters we should have something using Multicast (ideally a native JavaGroups) for both side.
With such the configuration in both Web and Tomcat clusters will be
to enter a Service Channel where all members will get all the services messages and handle them accordingly ?
What about multicast support in APR ?
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
