tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-frederic Clere <jfcl...@gmail.com>
Subject Re: JK and AJP protocol enhancements
Date Thu, 13 Jul 2006 09:56:00 GMT
Henri Gomez wrote:

> Well there was some provision in mind in AJP 1.4 :
>
> Context informations forwarding for Servlet engine to Web Server
>
> With this kind of information requested by webserver, we could
> determine the version of Servlet  AJP implementation and as such use
> 32/64k buffers.
>
> the jk could send question like 'do you support 32k buffers ?'

In fact it should start the first dialog by asking the version of AJP TC 
is supporting, otherwise we will never be able to improve the protocol.
Probably a CPING answered by a PONG + version before the first request.

Cheers

Jean-Frederic

>
> In fact, the idea was to help jk side to discover information on the
> Servlet engine implementation, and act accordingly.
>
> 2006/7/10, Mladen Turk <mturk@apache.org>:
>
>> Costin Manolache wrote:
>> > 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 point is that it will be backward compatible.
>> It means that for headers < 8K any current AJP 1.3 protocol
>> could be used as is.
>> If there is a larger header, then the current AJP1.3 implementation
>> will return 'error message' (as now), while the new one will
>> handle it by requesting additional header packets.
>> Also if the old 1.3 consumer is in front of the new 1.4 producer
>> nothing will change.
>>
>> Resolving 8K header limitation and allowing a single header to be
>> larger then 33K, while presere the backwards compatibility and it can
>> be done. It would make receiver and producer a little bit more
>> complex, but not that much. It would still maintain the zero-copy
>> failover, that IMHO is the major advantage of AJP protocol, without
>> the need to prefetch the entire header data.
>>
>> Regards,
>> Mladen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message