mod_fastcgi 2.0 beta 1

Stanley Gambarin (gambarin@OpenMarket.com)
Wed, 30 Apr 1997 14:48:35 -0400

Message-Id: <199704301848.OAA01371@u4-138.openmarket.com>
To: fastcgi-developers@OpenMarket.com
Subject: mod_fastcgi 2.0 beta 1
Date: Wed, 30 Apr 1997 14:48:35 -0400
From: Stanley Gambarin <gambarin@OpenMarket.com>

	Greetings, fastcgi developers:

	Trying to keep in sync with the recent developments of the Apache web
server, a new version of mod_fastcgi will be available on the web immediately.
This new version provides a number of bug fixes, which were fixed due to your
reports.  It also includes a few new features, which are described below:
	- a new restart cleanup scheme was implemented to provide reliable 
killing of the fastcgi processes.  The former setup had only allowed the 
process manager 3 seconds to kill all its children, i.e. fastcgi processes.
The new setup decouples the dependence of the process manager to the Apache
core through the use of intermediate process.  This allows for implementation
of the reliable cleanup without any changes to the Apache API (even though
the later could have been done with 3 lines of code in Apache, oh well).
	- fastcgi applications can now be started without having an explicit
declaration via an AppClass directive.  An additional directive, FCGIConfig
was provided to allow the configurations of various parameters which govern
the execution and termination of the dynamic fastcgi processes.  There are a couple
major issues involved in using the dynamic fastcgi applications:
	1. Dynamic applications are started and terminated dynamically, so 
that if you are relying on some fastcgi application, your best bet is to use
static, i.e. configured via AppClass, fastcgi applications.  However, if you have
some funky application that you want to try out, you will not have to restart the
server, but instead can use dynamic applications.
	2. In my very limited testing of the dynamic applications, I came across
a possible bug, where the two almost silmultaneous accesses were made to the same
fastcgi application.  The application code was of the form 
	print("text/html\r\n");
	sleep(10);
	print("Hello world");
	The version of the above program written in C ran fine, spawning off 2 
copies of the application and servicing them.  However, the same program written
in Perl (Perl 5.003_26 with Sfio 0.28 under Solaris 2.5) resulting in hanging the
server and never returning the request.   Furthermore, any subsequent requests to
any other fastcgi application did not go through.  I am assumming that there might
be some race condition in Perl's accept() loop, however I don't have to time to 
delve into it (see below).  So, a valid warning is that if you are planning to 
develop fastcgi apps targeted as dynamic application, use C as programming language
of choice.  Also note that above discussion does NOT apply to statically configured
Perl Fastcgi applications.
	3. The implementation of the dynamic fastcgi application is a very 
complex piece of code (at least for me).  Even though I had tried to minimize 
the possible occuring errors, I can also produce some faulty code :).  If you 
encounter an error, please check your log files for any messages that are 
outputted and enclose them in your problem description.  This will aid in the
tracking of the bug.
	- a full description of the new features can, as always, be found in 
the README file, enclosed with the distribution.  The options to the new 
FCGIConfig directive, can be found in mod_fastcgi.html, also distributed.

	The web site is not updated, but you can get the latest release of the 
mod_fastcgi module at http://www.fastcgi.com/servers/apache/2.0/apache-fastcgi.tar.Z

							Stanley.
Please read this too:
^^^^^^^^^^^^^^^^^^^^^
	I am sorry to inform that I will no longer be supporting fastcgi, as I am
leaving OpenMarket to pursue my other goals.  Thus, you should send any mail 
ragarding the fastcgi to the mailing list, instead of sending it directly to me, 
as some of you have been doing in the past.  This is also a reason, why the current
release is declared as beta, as I would have liked to do a more detailed testing of
it prior to the official release.  Also, because of the above, do not expect any 
new features in the mod_fastcgi in near future, as both fastcgi module and Apache 
web server are now entering into a maintainance stage and it would be wasteful to
provide new functionality if the module API is going to significantly change.  There
will be, as usual, bug fixes in the subsequent releases.
	It has been a fun ride with FastCGI.  I am pretty sure I will still be on
the mailing list, except that I will not be doing anymore active development.  If 
you have some questions, feel free to contact me prior 05/02/97 via this email
or via phone (617)949-7487
							Stanley.