On Wed, Apr 14, 2010 at 1:52 PM, Jeff Trawick <[email protected]> wrote: > On Fri, Apr 9, 2010 at 9:49 AM, Darren Garvey <[email protected]> wrote: >> On 9 April 2010 13:39, Jeff Trawick <[email protected]> wrote: >>> >>> On Wed, Mar 31, 2010 at 10:56 AM, Darren Garvey <[email protected]> >>> wrote: >>> > On 31 March 2010 15:49, Jeff Trawick <[email protected]> wrote: >>> >> >>> >> On Wed, Mar 31, 2010 at 7:05 AM, William A. Rowe Jr. >>> >> <[email protected]> wrote: >>> >> > On 3/31/2010 5:41 AM, Jeff Trawick wrote: >>> >> >> On Wed, Mar 31, 2010 at 6:26 AM, Darren Garvey >>> >> >> <[email protected]> wrote: >>> >>> >> >>> Does anyone know if there is any other way to communicate with >>> >> >>> mod_fcgid on Windows besides anonymous pipes? >>> >>> >> > Isn't httpd 2.3 alpha mod_proxy_scgi ment to do this? >>> >>> >> mod_proxy_fcgi at least ;) (I meant to add that earlier) >>> >> >>> >> mod_proxy_* is httpd's way to route/loadbalance/manage connections to >>> >> externally managed servers of various types >>> >>> > Ahh, this might be what I'm looking for. Is >>> > http://mproxyfcgi.sourceforge.net/ the same thing? It looks like >>> > mod_proxy_fcgi is in trunk now but this link has a user guide. :) >>> >>> hmmm, looks like the same idea (hopefully that's a good sign)... >>> mod_proxy_fcgid in httpd trunk was started from scratch some 4 yrs >>> ago... >> >> Ok so, does mod_proxy_fcgid in trunk work? It would be nice to test my >> FastCGI code with an external configuration (with async I/O) on Windows. For >> now I'm just using pipes which - apart from blocking on read/write - seem to >> work fine. > > Does it work? Well, sort of... > > Here's my first attempt: > > $ cat ~/inst/23/conf/conf.d/proxy-fcgi.conf > ProxyPass /info fcgi://127.0.0.1:9999/ > > $ support/fcgistarter -c ~/myhg/apache/fcgid/apps/info.pl -p 9999 > > (uh, fcgidstarter needed a fix to work on my system) > > $ cat ~/myhg/apache/fcgid/apps/info.pl > #!/usr/bin/perl > > use strict; > use CGI::Fast; > > my $count = 0; > while (my $q = CGI::Fast->new) { > print("Content-Type: text/plain\n\n"); > print("Process ID: $$; Count is: " . ++$count . "\n"); > > print "VHOST: $ENV{'VHOST'}\n"; > print "WHO: $ENV{'WHO'}\n"; > print "User-AgenT: $ENV{'User_AgenT'}\n"; > } > > It worked for a few requests, after which the Perl FastCGI engine got > out of sync and blocked in read(). > > Perhaps others have had better results? (Yeah, I should shut up and > find the problem.)
Proxy holds open the back-end connection by default, so that it doesn't have to reconnect when the same httpd child process needs to send the app a request. I have a single instance, single threaded FastCGI app, effectively waiting for a subsequent request on that held-open back-end connection, which won't happen until the same httpd child process handles another request. Disabling reuse resolves that problem: ProxyPass /info fcgi://127.0.0.1:9999/ disablereuse=on
