tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Costin Manolache" <>
Subject Re: JK and AJP protocol enhancements
Date Sun, 09 Jul 2006 14:29:56 GMT
What's the status with mod_proxy ?

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.
- json
- 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.


On 7/9/06, Mladen Turk <> 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message