httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: mod_proxy_ajp - The purpose of FLUSHING_BANDAID
Date Tue, 07 Mar 2006 23:40:23 GMT

On 03/07/2006 11:43 PM, Justin Erenkrantz wrote:
> On 3/7/06, Jim Jagielski <> wrote:
>>I would suggest that the "bandaid" code no longer be
>>compile time but rather runtime, using a
>>"force-flush=true" param to the AJP worker.
> I'd prefer that we not defer this decision to the users - we should
> either enable it or don't.  But, most admins won't have enough
> knowledge to know when to force flushing or not.

I think it is ok to keep it configurable because either way (flush or non
flush) does not match for everybody. It is important to have a good
default value. From my first point of view having flushing enabled via
the poll code or having flushing disabled when flushing means 'flush after
each packet' sounds good to me.
OTH I guess we still have to convince some people to switch from mod_jk
to mod_proxy_ajp. So I guess having a similar behaviour in mod_proxy_ajp
as in mod_jk will ease this. Default for mod_jk is: No flushing.

BTW: If we decide to add a force-flush parameter it might make sense to make
mod_proxy_http also aware of it, as the current EAGAIN approach (which
I like) does not work, because the read from the backend is always blocking.
There is currently no possibility at all to force a flushing. There have
been some people on dev@ who complained about this.

> Unless/until AJP has a protocol revision, I think the code should stay
> and be enabled by default.  The only 'right' fix is to correct the
> buggy underlying protocol.  -- justin

I think everybody here agrees that is the only correct fix, but we have to take
into account that there will be a lot of older Tomcat installations in the wild
that cannot be upgraded to a new major version for whatever reasons (as I understand
only Tomcat 6 is in discussion to support a possible new AJP flush message), but need
flushing. For them we should provide a workaround like the force-flush parameter.

The question that remains open to me is what kind of implementation should be used
if force-flush is set to true?

The poll approach in the current code or flushing after each packet?

Although the poll approach can 'guess' things wrong I think it adapts better to
mixed backend resources (ones with flush() and ones without).
OTH Mladen says it slows down mod_ajp_proxy by 10%. It would be interesting to compare
this with flushing after each packet.



View raw message