Re: [fwd]Apache/Linux/FCGI returns partial page

Stanley Gambarin (gambarin@OpenMarket.com)
Wed, 29 Jan 1997 10:57:48 -0500

Message-Id: <199701291557.KAA22813@u4-138.openmarket.com>
To: fastcgi-developers@OpenMarket.com
Subject: Re: [fwd]Apache/Linux/FCGI returns partial page 
In-Reply-To: Your message of "Wed, 29 Jan 1997 10:14:58 EST."
             <199701291514.KAA22690@u4-138.openmarket.com> 
Date: Wed, 29 Jan 1997 10:57:48 -0500
From: Stanley Gambarin <gambarin@OpenMarket.com>


> >I would like to note a few minor things that you probably 
> >already know about:  The instructions for installing FCGI
> >and updating Perl do not handle the case for the latest version 
> >of perl.c under 5.003...so some people may have problems with 
> >misinterpreting the instructions on your page. The new perl.c 
> >does not need the patch.
> >
	Since I am not very familiar with Perl and do not use it in
everyday development, I would appreciate any outside effort on 
documentation on how to use Perl/FastCGI, how to build it, etc., 
especially from people who use Perl regularly to do actual work.

> >Unless I use the -processes flag set to 1 then 2 instances 
> >of the fcg are created when I restart httpd.  The -listen-queue-depth 
> >flag is not recognized and gives me an error so I can't use it :-( 
> >
	The first problem is related to Apache and has been discussed in 
great detail before (but I will repeat anyways).  Upon restart, Apache sends
a SIGTERM to each of its children (one of which is process manager for 
FastCGI processes).  It then waits something like 3 seconds and then sends
SIGKILL.  During those seconds, if the process manager is unable to kill off
its children (i.e. FastCGI processes), since it maybe sleeping, the process
manager is killed, but the FastCGI process remains (even though its now 
orphaned - to check, run ps(1) program and see that the PPID - parent pid - 
of one of those FastCGI processes is 1 - meaning no parent).  Solution
would involve changing Apache API, which is not currently feasible right now.
	The "-listen-queue-depth" flag is a part of the mod_fastcgi.c and
should be processed just fine.  The only problem that i can think off is that
the parameter passed to it might be a cause for the above problem.  I would
appreciate more detailed report on that problem.

> >Okay..now the real problem:
> >I've written a fastcgi chat script (http://www.faxus.com/fcg/chat3.fcg)
> >that runs fine for a while...It's single threaded and has a message 
> >queue as an associative array.  After the chat is running for 'a while'
> >I start to get these errors intermittently:
> >
> >mod_fastcgi.c:1637: failed assertion `count >= 0 && count <=bufPtr->length'
> >
	This problem was reported before, however there is not enough 
information to provide a fix.  The most likely offending piece of code 
was traced to CgiToClientBuffer() routine, where the call to 
BufferToss(infoPtr->inbufPtr, infoPtr->paddingLen) should be replaced by
BufferToss(infoPtr->inbufPtr, len).   I would appreciate someone who can 
reproduce the problem to run the above fix and see if it solves the 
problem, so that it may make it into the next release.

> >Here's some errors that show up in Apache's error_log:
> >
> >[Thu Jan 23 10:14:02 1997] - lingering_close
> >[Thu Jan 23 10:16:59 1997] accept: Connection reset by peer
> >[Thu Jan 23 10:16:59 1997] - socket error: accept failed
> >[Thu Jan 23 10:18:20 1997] accept: Connection reset by peer
> >[Thu Jan 23 10:18:20 1997] - socket error: accept failed
> >[Thu Jan 23 10:18:20 1997] accept: Connection reset by peer
> >
	The above excerpt from the log warrant a piece of attention.  
Apache server developer group is currently investigating a problem with
regard to lingering_close (first entry).   This problem is due to some 
interactions between OS and how it handles the network connections and 
is operating system dependent.  It also results in the large number
of sockets being left in FIN_WAIT_2 state (meaning that server waits for
the socket to close), resulting in large number of extra server processes
being created.  For more description of the problem, take a look at the
apache web site, http://www.apache.org and for the possible solution take a
look at http://www.worldgate.com/~marcs/fin_wait_2.html

						Hope that was of some help.
							Stanley.

-- 
*******************************************************************************
* To unsubscribe from the fastcgi-developers mailing list		      *
* 		mailto: fastcgi-developers-request@openmarket.com      	      *
*		with body containing: unsubscribe       		      *
* To request help for using the fastcgi-developers mailing list		      *
* 		mailto: fastcgi-developers-request@openmarket.com      	      *
*		with body containing: help		       		      *
*******************************************************************************

*******************************************************************************
* Stanley Gambarin			Open Market Inc.		      *
* FastCGI (soon-to-be) Guru		245 First St. Cambridge MA 02142      *
*					(617) - 949 - 7487		      *
* mailto:gambarin@openmarket.com					      *
* 				http://acs2.bu.edu:8001/~stanleyg (school)    *
*				mailto:stanleyg@cs.bu.edu		      *
*******************************************************************************