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.