httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: AW: mod_proxy_ajp - The purpose of FLUSHING_BANDAID
Date Tue, 07 Mar 2006 14:46:11 GMT
As someone who depends on such flushing I'd echo that we don't need 
flushing after every AJP packet -- just when we explicitly call flush().

Plüm wrote:
>   
>> -----Ursprüngliche Nachricht-----
>> Von: Mladen Turk 
>>
>>
>>     
>
> First: I am the author.
>
>   
>> Hi,
>>
>> I would love that we remove the FLUSHING_BANDAID from the code
>> because it concept breaks the AJP protocol specification.
>>     
>
> I do not understand how this breaks the spec. There might be reasons
> to handle this differently, but I see no violation of the specs.
> The flushing bandaid simply tries to detect whether it needs to add
> a flush bucket or not after the data of *one* packet has been added
> to the brigade.
> So if buffering the data in the core output filter without the flushing
> bandaid or with flush=off does not break the spec and if setting
> flush=on does not break the spec how does the flushing bandaid
> breaks this?
>
>   
>> Instead FLUSHING_BANDAID I propose that we introduce a new
>> directive 'flush=on' that would behave like the most recent
>> mod_jk directive 'JkOptions +FlushPackets'.
>>     
>
> The drawback of this solution form my point of view is that
>
> - The user has to configure it
> - It is a bang bang switch: Either you flush after each packet
>   or never do explicit flushing (apart from the case that the
>   core buffer is filled).
>
> BTW: mod_proxy_http also tries to be that intelligent, but it does not
> work as the EAGAIN handling does not work as expected and httpd
> always reads in blocking mode from the backend.
>
>   
>> The point is that the AJP protocol is packet based, so trying
>> to mimic the 'stream' behavior is bogus.
>> Further more, this (FLUSHING_BANDAID) does not resolve the
>> explicit flush from the application server, because it take
>>     
>
> Ok, it does not do this exactly, but in most cases it works, because
> if you flush data explicitly on the application server it usually takes
> some time until you sent the next data.
>
>   
>> care only on the transport rather then a spec.
>>
>> I know that for such cases we would need to extend the AJP
>> protocol with explicit flushing, but for now the only solution is
>> to have an directive that will flush on each packet.
>>     
>
> That seems to be the final solution to me. Something like a
> SEND_BODY_FLUSH AJP message.
>
>   
>> So, since FLUSHING_BANDAID has none particular usage I'm asking
>> the author to remove that code, so we can work on a packet
>> flushing rather then a time based one.
>>
>>     
>
> I am happy to discuss a better solution. As the name says it is
> a BANDAID :-).
> So I am keen on additional proposals / comments on this.
>
> As a summary from your side I see:
>
> 1. Extend AJP protocol [The desired target from my view].
> 2. Add an option to flush after every AJP packet [has some drawbacks from my
>    point of view (s.o).]
>
>
> Regards
>
> Rüdiger 
>
>   


Mime
View raw message