On Mon, Feb 1, 2016 at 3:32 PM, Ruediger Pluem <rpl...@apache.org> 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 be > 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. +1 > 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 first > brigade at least some of them would process the buckets directly without > setting them aside. > 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 case). 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. Regards, Yann.
