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 Sat, 04 Apr 2009 14:33:20 GMT
On Sat, Apr 4, 2009 at 1:10 AM, Mladen Turk <> wrote:

> 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 think it is good to separate marshaling from the transport and the actual
service API. Our main value is the API - simple forwarding, async
load info, etc. After we implement the primitive - it is possible to expose
over multiple transports - socket, unix, etc and even marshal the messages
using different libraries. We could even expose an API over plain HTTP (
mux-ing ). I am only suggesting one marshal library ( at least for start ),
a small changes to the transport we have.

The API can be something like:
- legacyRequest(RequestMessage) - whatever we have in the current AJP
- getServerLoad() and whatever new we wanted to add

Instead of defining AJP extensions, we just pick one of the marshalling libs
and use them
for encoding the new methods.

Later we can add:
- asyncInputData(reqId, Data) - on tomcat
- asyncSendData(reqId, Data) - on web server

For transport - we can keep most of the current code, but for async we need
to stop waiting for
a response to each request, and use a request ID ( or 'channel ID' ) and
I think this can be done without a huge effort, and incrementally - i.e.
alongside the
existing code, reusing what we have. Well, maybe I'm underestimating, but
I'm pretty sure
the harder part will be agreeing on details like what marshaling to use,
what branch and
review process - can anyone veto a proto/api he doesn't like, etc :-) That's
why I'm suggesting
that long term we could support multiple marshalling and API extensions, if
there are strong
religious reasons.

In any case - there are quite a few mux protos out there - SSH proto, PPP,
few in w3c /, etc,
and most can use any payload ( marshalling/api ).

And for 'human readable' - I can throw in XMPP as an alternative to your
wsgi :-)


>>> 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.
> Regards
> --
> ^(TM)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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