tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mladen Turk <>
Subject Re: [Proposal] Remove older of the two BIO AJP connectors
Date Sat, 04 Apr 2009 08:10:25 GMT
Costin Manolache wrote:
>>  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.

Sure, but then you force everyone that wish to talk to you
to use the same framework. The same thing can be done
with a pencil and a peace of paper cause we only need one
protocol, not zillion of them.
So in essence you have a new protocol but the sole
difference is how you describe it.

None of them has multiplexing (Google protobufs doesn't even
have the transport layer just marshal/unmarshal, while thrift
transport is unix only).
The only OSS solution that I know is w3c's http mux, but that's only
Java part and IMO incompatible with ASL license.

>> 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
> description
> of the communication protocol - i.e. the marshaling, framing, etc ? I don't
> mind
> 'human readable', or even supporting multiple formats. Are they multiplexing
> or
> request-waiting-response ? Do they already define methods for load
> balancing, etc ?
> If yes - sure, it's one valid option.

Sorry, Costin I was pulling your leg with that.
It's an example of where we could end up eventually.

In essence there is no webserver/backend (proxy) protocol
or standard that exists and that is usable with
async, security, rpc and multiplexing support. Period.

The only dedicated one were AJP and FCGI, but both
were designed with web.0 in mind.


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

View raw message