Agreed. r->pool for the win.
> On Jul 14, 2017, at 5:38 AM, Plüm, Rüdiger, Vodafone Group
> <ruediger.pl...@vodafone.com> wrote:
>
>
>
> Von: Luca Toscano [mailto:toscano.l...@gmail.com]
> Gesendet: Freitag, 14. Juli 2017 11:30
> An: Apache HTTP Server Development List <dev@httpd.apache.org>
> Betreff: Re: mod_proxy_fcgi and flush
>
> Hi Yann,
>
> 2017-07-13 22:15 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>:
> On Thu, Jul 13, 2017 at 7:36 PM, Luca Toscano <toscano.l...@gmail.com> wrote:
> >
> > 1) read the FCGI headers to gather how much data the record is carrying
> > (clen)
> > 2) read the data in iobuf_size batches, sending each time the bytes
> > collected to the output filter chain.
> > 3) finally read the padding bytes (if any).
> >
> > I tried to use the same trick as mod_ajp for flushpackets=auto, but apr_poll
> > returned immediately most of the times due to the padding bytes ready to
> > read (took me a while to realize this simple thing).
>
> I forgot some details about proxy_fcgi so am asking before (re)looking at it
> :p
>
> Can't we poll() after 3) ?
> If so, maybe we could flush only if a small/zero timeout poll() times
> out, and hence still be able to coalesce multiple (closed) records.
>
> http://home.apache.org/~elukey/httpd-2.4.x-mod_proxy_fcgi-force_flush-v3.patch
> created, I tested it quickly and it seems working fine (still unsure about
> using r->connection->pool vs conn->pool in palloc). More tests following in
> the weekend :)
>
> r->pool is the correct pool to use.
>
> Regards
>
> Rüdiger
>
> Thanks for the hint!
>
> Luca
