tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [Proposal] Remove older of the two BIO AJP connectors
Date Fri, 03 Apr 2009 18:17:24 GMT
On Fri, Apr 3, 2009 at 10:24 AM, Mladen Turk <> wrote:

> Costin Manolache wrote:
>> +1 on removing from trunk.
>> IMHO AJP as a protocol is a dead end - it is not worth extending,
> Agreed. It has to many limitations to satisfy the
> modern webserver/backend connector.
>  and certainly not
>> worth creating a new protocol. We need to pick one of
>> thrift/protobuf/hessian for
>> marshaling, and start doing some mux-ing in the protocol.
> All those framework you mention are just helpers for
> *building* the custom protocol. They actually mandate
> that we will have one but now hidden inside some IDL
> language description. Any such framework makes
> almost impossible to change the protocol specification
> while preserving backward compatibility
> (One huge problem why AJP is not usable any more)

You preserve backward compat by keeping the protocol stable
and supporting all methods you define in the IDL. What is needed
is bi-directional communication between web server and tomcat -
so you can do all the extensions on the list.
The stability of the actual method definition is probably more important
than the protocol itself - if we start using an IDL, it is even possible to
expose the methods over multiple protocols if there is a
compelling reason.

> I'm kind of more fun of
> At least it's human readable and already working :)

Well, the spec is not so human readable :-) - can you point me to the
of the communication protocol - i.e. the marshaling, framing, etc ? I don't
'human readable', or even supporting multiple formats. Are they multiplexing
request-waiting-response ? Do they already define methods for load
balancing, etc ?
If yes - sure, it's one valid option.


> Regards
> --
> ^(TM)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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