tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Some JK2 ideas v.3
Date Tue, 20 Jul 2004 15:02:10 GMT
Henri Gomez 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....

This sound like a lot of features. I'm sure others will be added to the 
list by other people. That is my concern - it seems the assumption is 
this will be a very simple module, so there is no need for modularity or 
  a flexible design. On the other side, just like in all other "it's 
going to be very simple" cases, features will keep piling.

It's one thing to have just apache2 module and ajp13 ( and nothing 
more), another thing to have all the above.

The real problem is:

1. figuring the list of features.
- I agree multiple protocols ( incl jni) and multiple servers should be 
- We seem to agree on having "cluster reconfiguration" feature.
- I'm not sure if we agree or not on dynamic add/remove of webapps.
- It seems I'm alone in wanting monitoring and finer reconfiguration.
- we agree on strong integration with the server
- I'm not sure about about the "add/remove" of webapps versus "strong 
integration" - I haven't seen any answer on how they can work togheter, 
it seems Mladen solves this by removing "add remove webapps", which IMO 
is bad. I just don't know how you can have both at the same time - the 
only solution I found so far is to have 2 operating modes.

2. design. It seems a lot of people believe this will stay "simple" and 
there is no need for a flexible design  (i.e. components, etc ). If it 
is a clear understanding that the feature list will be frozen - i.e. if 
you want more features, you'll need to write a new module from scratch 
and not reuse anything from this - then it may work, but I never seen 
this happening in open source.

If C-Mbeans are too complicated - then maybe we can use GObject ( from 
gnome ) or XPCom components ( from mozilla ) ( or some subset of it). 
But please, don't start another "simple" project that in a year will 
have to be rewritten. Object oriented programming does have some value:-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message