On Wed, Jul 19, 2017 at 12:44 PM, Luca Toscano <toscano.l...@gmail.com> wrote:
> Hi Yann,
> 2017-07-19 13:56 GMT+02:00 Yann Ylavic <ylavic....@gmail.com>:
>> On Wed, Jul 19, 2017 at 1:45 PM, Jim Jagielski <j...@jagunet.com> wrote:
>> > There's nothing in the way we handle UDS that prevents "reuse"
>> > even understanding that we use the term "reuse" to mean both
>> > "cache the IP address" and "use the connection as a one-shot".
>> > There's no diff between UDS and sockets from the module PoV.
> +1 as well, this is my understanding too.
>> The comment in proxy_fcgi says:
>> /* This scheme handler does not reuse connections by default, to
>> * avoid tying up a fastcgi that isn't expecting to work on
>> * parallel requests. But if the user went out of their way to
>> * type the default value of disablereuse=off, we'll allow it.
> This comment in the code was also a bit weird, what does it mean "a fastcgi
> that isn't expecting to work on parallel requests" ? Even if reuse is off
> multiple FCGI requests can land to the same FCGI backend at the same time
> no? What does reuse=on do more other than forcing a worker to reuse the same
I think this comment is OK, but the related comment in the manual is bad.
I think the original concern was some FastCGI that would not even
accept() two connections. Keeping one
idle in httpd process A would not allow another httpd process B to
dispatch to the FastCGI because it is waiting on the first connection.
But, this must be the case in only the most primitive hello-world of FastCGI's.