httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VIS <>
Subject AW: mod_proxy_ajp - The purpose of FLUSHING_BANDAID
Date Tue, 07 Mar 2006 14:23:40 GMT

> -----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

> 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).]



View raw message