Re: FastCGI errors after timeout

It's possible your FCGI gets stuck, as I mentioned in my initial reply. If your
FCGI loop does not return due to some error in your code, there will no longer
be any available FCGI to process new requests. You should test a simple 'hello
world' FCGI and if there is no problem, then the problem is with your application.
No FCGI configuration would fix your application for you. If your application gets
stuck and there are no more instances of FCGI available to process new requests,
all subsequent requests would fail after being backlogged and timeout period
elapsing. If your are not experiencing a high load, then this is exactly what's
happening. With just 2 FCGI processes, you will only need to have 2 requests
screw up (get stuck) for all subsequent requests to timeout. If the backlog (queue)
gets full after all FCGI process are stuck, you will receive: cannot connect to
server error.

-Simon 

On Wed, 29 Dec 2004 17:44:07 -0500, Allen wrote:

>Simon wrote:
>> 
>> When all FCGI processes are busy and queue is full, you will receive:
>> FastCGI: failed to connect to server
>> 
>> So, make sure your queue is large enough and that there is enough FCGI
>> serving processes, otherwise what you describe will occur. The best approach
>> is to make sure your FCGI requests do not take longer than few seconds
>> to complete or you will need many FCGI processes to make things scalable.
>> Also, if your FCGI processes get stuck, no matter how many FCGI processes
>> you have, it will be very easily to DoS your FCGI pool.
>> 
>> -Simon
>
>Thanks, Simon.
>
>The FCGI hits were not that frequent during this time, so we don't have 
>a problem with the number of FCGI process. Also, we have never had a 
>problem handling a higher load with just 2 FCGI processes running, a 
>testament to FCGI! We are also working to resolve the underlaying 
>timeout problem.
>
>However, the problems appears after that single timeout occurrence, when 
>there are no more timeout conditions, and degenerates from there. I am 
>assuming the errors come from mod_fastcgi, but perhaps they originate in 
>  the Perl CGI::Fast client the the FCGI process?
>
>I am still hoping there is a configuration parameter or a resolution 
>from anyone else experiencing the same effects. :-)
>
>Allen
>
>> 
>> On Tue, 28 Dec 2004 21:18:05 -0500, Allen wrote:
>> 
>>  >We been using FastCGI (mod_fastcgi) for a year and it has been working
>>  >great. Recently and without configuration changes, we've experienced a
>>  >problem.
>>  >
>>  >After a "timeout" condition (a transaction exceeded the 30-sec limit),
>>  >successive transactions caused FastCGI "failed to connect to server"
>>  >errors in the apache error_log, and eventually the CGI processes
>>  >starting to die after the first execution. After an apache graceful
>>  >restart, the problem goes away until the timeout occurs again.
>>  >
>>  >Anyone have this problem, solutions or suggestions?
>>  >
>>  >Details:
>>  >
>>  >We use FastCGI to invoke a Perl process to handle straightforward API
>>  >calls to our system. This api-server process stays resident and
>>  >persistent and holds onto database connections to remove the overhead of
>>  >a large number of database connects and Perl runtime initialization.
>>  >
>>  >The api-server itself is configured to self-end after 10 minutes of
>>  >runtime, to keep things "fresh". FastCGI automatically starts another
>>  >process when this occurs, and it all works wonderfully.
>>  >
>>  >Due to other long-running database-related processes on the system,
>>  >there comes a time where the PostgreSQL database becomes unresponsive
>>  >for a period of about 4 minutes at a time. This is certainly not
>>  >desirable, and we are also working to resove this issue.
>>  >
>>  >However, when this occurs, the currently executing FastCGI transaction
>>  >is blocked for the 4 minutes before it returns. The timeout of FastCGI
>>  >is set to the default 30 seconds, and it detects the timeout condition.
>>  >The following error messages result:
>>  >
>>  > [Thu Dec 16 22:06:56 2004] [error] [client xxx.xxx.xxx.xx]
>>  > FastCGI: comm with (dynamic) server
>>  > "/path/bl-api-server.fpl"
>>  > aborted: (first read) idle timeout (30 sec)
>>  > [Thu Dec 16 22:06:56 2004] [error] [client xxx.xxx.xxx.xx]
>>  > FastCGI:incomplete headers (0 bytes) received from server
>>  > "/path/bl-api-server.fpl"
>>  >
>>  >After that each transaction encounters the same problem and occasionally
>>  >this error:
>>  >
>>  > [Sun Dec 19 05:59:42 2004] [error] [client 207.218.164.32]
>>  > (61)Connection refused: FastCGI: failed to connect to server
>>  > "/path/bl-api-server.fpl": connect() failed
>>  > [Sun Dec 19 05:59:42 2004] [error] [client 207.218.164.32]
>>  > FastCGI: incomplete headers (0 bytes) received from server
>>  > "/path/bl-api-server.fpl"
>>  >
>>  >During this period, FastCGI keeps starting api-server processes which
>>  >run the transacation successfully, but then disappear. It does not
>>  >appear that the process is ending naturally, but I suspect there maybe
>>  >in issue with the Perl interface to FastCGI in holding the connection to
>>  >the parent process.
>>  >
>>  >After an apache graceful restart, the problem goes away.
>>  >
>>  >On inspection of the api-server logs, each transaction was properly
>>  >started and successfully executed, most within a second each. The error
>>  >message after the response problem cleared continued to appear although
>>  >the process did finish normally and long before the timeout period. I am
>>  >not certain if the result HTTP page response was properly sent, though I
>>  >assume not from these messages.
>>  >
>>  >We are currently running FreeBSD 4.6.2-RELEASE-p2, FastCGI verion
>>  >mod_fastcgi-2.4.2, Apache 1.3.26, Perl version 5.005_03, and Perl
>>  >interface to FastCGI veriosn $CGI::Fast::VERSION='1.01';
>>  >
>>  >Thanks,
>>  >Allen
>



___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/