httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: svn commit: r1726787 - /httpd/httpd/trunk/modules/proxy/mod_proxy_wstunnel.c
Date Mon, 01 Feb 2016 14:54:31 GMT
On Mon, Feb 1, 2016 at 3:32 PM, Ruediger Pluem <> wrote:
>> I am fine with flushing at the end of the loop. If no one opposes I can do this.
> Looking into this in more detail the following thoughts came up:
> What do we think how much iterations do we do in this loop in the typical case
> a.k.a how often do we call ap_get_brigade with a non blocking read?
> My gut feeling tells me that we only do this once at least in the websocket case.

I guess it depends on the size of the outgoing traffic, it the backend
sometimes sends large data at once we may end up needing more than one
non-blocking read (AP_IOBUFSIZE/8K each) to forward the fragments.

> If this is the case the discussion whether to flush after the loop or in the loop wouldn't
> relevant any longer, but more important:
> If it is ok to flush in the loop I think it would be better to add the flush bucket
> directly to bb_out instead of calling ap_fflush afterwards. The reason for this is
> that it gives downstream filters a better information on what they should do.


> With the current
> approach they might set the buckets aside and store them for later processing and only
> process them in the second round when they see the flush. If the flush would be on the
> brigade at least some of them would process the buckets directly without setting them
> Comments?

That's the "issue" with transient buckets, the core output will almost
always set them aside if not flushed (including in the mod_proxy_http
It wouldn't have to (or this would be a noop) if the buckets were
allocated on its bucket_alloc instead of the origin's.
But I agree that for now your approach makes sense.


View raw message