tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-frederic Clere <jfcl...@gmail.com>
Subject Re: JK and AJP protocol enhancements
Date Mon, 10 Jul 2006 07:23:08 GMT
Costin Manolache wrote:

> What's the status with mod_proxy ?

I think Mladen idea is to make the same enhancements in mod_proxy (and I 
will try to help him :-)

>
> It seems this kind of change would break backward compatibility, and 
> if this
> happens - maybe it's better to fix the protocol marshalling 
> limitations or
> change it completely.
> I hate the idea of patching an old and mostly broken marshalling model.
>
> The only thing we still need is the alternating client/server role 
> using a
> single tcp connection. For the actual marshalling, there are plenty of
> better choices - with more extensibility,  self-describing, easy and 
> fast to
> parse, etc.
> Examples:
> - json
> - http://www.caucho.com/resin-3.0/protocols/hessian-1.0-spec.xtp
> - yaml.org
> - wbxml if we want very compact representation
>
> ( every time someone is discussing extending AJP I feel the need to point
> that ajp is a very old and not so well designed protocol, it was not
> supposed to live that longer and there is no need for a proprietary,
> tomcat-specific marshalling mechanism )
>
> I realize that replacing the serialization code would be a large 
> effort, but
> I think using a proper format, with existing implementations ( to 
> allow easy
> testing ) is far simpler than patching ajp and having all kind of
> workarounds and tricks.

I am quite reluctant to use a new (for our community) protocol... I 
rememeber the WARP protocol years ago.
Probably patching the old crapy protocol will have more success than 
doing a nice new thing :-(

Cheers

Jean-Frederic

>
> Costin
>
> On 7/9/06, Mladen Turk <mturk@apache.org> wrote:
>
>>
>> You see how desperate I am when writing this on Sunday :)
>>
>> Anyhow, we are pretty close to the new JK release that I
>> hope will be the most usable and stable whatsoever.
>>
>> The things we agreed so many times before, but having
>> obviously too little resources to actually create are
>> the 1.3 branch (aka JK3) and the AJP protocol stuff.
>>
>> Now there is the problem with that. Henri even created
>> a AJP1.4 protocol enhancements with all that login,
>> discovery etc... (never implement but thats another story).
>> Although we got close to the AJP 1.4 protocol conclusion
>> last year, nowadays all that looks strange to me.
>> All those things might be implemented, but IMHO only
>> as a AJP1.5 protocol.
>>
>> What we desperately need right now are 3 things:
>> 1. Allowing to have +8K headers
>> 2. Allowing to have +0x9999 single header limit
>> 3. Mechanism to tell the Tomcat to gracefully close
>>     the connection.
>>
>> Now, the number 3 is very easy. A simple message
>> like we have for SHUTDOW, but instead shutting down
>> the entire Tomcat instance, closing down the socket/channel.
>>
>> OTOH first two are little bit tricky :)
>> I have some ideas:
>> 1. Larger headers can be treated as we handle the POST data.
>>     If there are more headers then 8K, then a servlet container
>>     should send GIVE_ME_MORE_HEADERS message.
>> 2. If the single header is larger then 39321 bytes, then it
>>     should be send as POST data, with servlet container requesting
>>     8K packets. Those headers would be treated as multiple POST
>>     sequences, after the initial header(s) packet(s) have been
>>     read and before the actual POST data is read.
>>
>> Any comments?
>>
>> Regards,
>> Mladen.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message