Re: Bug fix for mod_fastcgi

Thanks for the patch Joe.  Excellent catch.

I've incorporated a fix for this.  My approach varies from yours, but it
should achieve the same result.

Rob

> -----Original Message-----
> From: fastcgi-developers-bounces+robs=chelsea.net-VYFNfGabXYtBDgjK7y7TUQ@public.gmane.org
> [mailto:fastcgi-developers-bounces+robs=chelsea.net-VYFNfGabXYtBDgjK7y7TUQ@public.gmane.org] On Behalf
> Of Joe Strout
> Sent: Tuesday, March 25, 2008 4:25 PM
> To: [email protected]
> Subject: [FASTCGI] Bug fix for mod_fastcgi
> 
> [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/