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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
