Re: Bug fix for mod_fastcgi

Joe,

Thanks for pointing this out - Rob is going to take a peek tonight, and we'll 
look at rolling another SNAP shortly with this and a few other recent things 
that have popped up.

David.

-----

On Tue, 25 Mar 2008, Joe Strout wrote:

> [I posted this on 3/13, but nobody replied, and now I can't find it
> in the archives, so maybe the mailing list burped.  Here's trying
> again.]
>
> I dug into the mod_fastcgi source, and believe I have found (and
> fixed) the problem with timeouts with certain-sized responses.
> Here's what's going on:
>
> It can happen that we already have some data in the
> clientOutputBuffer before calling ap_select and fcgi_buf_socket_recv,
> to receive data into serverInputBuffer.  Then we call
> fcgi_protocol_dequeue, which will return after filling up
> clientOutputBuffer.  Then, if there is still more data to receive
> sitting on the socket itself, we're fine; ap_select will return
> happily on our next iteration and we finish processing the data.  But
> if not -- if we've emptied the socket into serverInputBuffer -- then
> ap_select times out, resulting in the "idle timeout" error.
>
> So there are really two related problems here:
>
> 1. The socket_io method (which implements the main state machine)
> uses some heuristics to calculate how long it should wait before
> timing out.  This includes a check for pending data to be sent to the
> client (clientOutputBuffer) -- but does NOT include a check for data
> that's already been received from the socket and is waiting to be
> processed (serverInputBuffer).  I think in this case we want to just
> poll the sockets without waiting at all, so I added an additional
> block before the else clause:
>
> 		else if (BufferLength(fr->serverInputBuffer)) {
> 			/* data already in input buffer, so just poll sockets and continue */
> 			timeout.tv_sec = 0;
> 			timeout.tv_usec = 0;
> 		}
>
> 2. When we're in this situation, and ap_select returns 0 indicating
> that no knew data was found, we should not consider it an error as
> long as we still have pending data in serverInputBuffer.  So I
> changed the "if (select_status == 0)" line to
>
>         if (select_status == 0 && !BufferLength(fr->serverInputBuffer))
>
> With these changes, I'm now able to serve files of any size without
> hanging.
>
> How and where do I go about submitting a patch to have this change
> reviewed and rolled into the standard distribution?
>
> Thanks,
> - Joe
>
>
> --
> Joe Strout
> Inspiring Applications, Inc.
> http://www.InspiringApps.com
>
>
>
> ___________________________________
> fastcgi-developers mailing list
> http://fastcgi.com/fastcgi-developers/
>
___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/