Skip Menu |
 

This queue is for tickets about the FCGI-Engine CPAN distribution.

Report information
The Basics
Id: 34488
Status: resolved
Priority: 0/
Queue: FCGI-Engine

People
Owner: stevan.little [...] gmail.com
Requestors: mpitts [...] a3its.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.03
Fixed in: (no value)



Subject: Unexpected behavior when "dropped-in" to Catalyst
Download (untitled) / with headers
text/plain 1.4k
I'm interested in writing a patch to add better process management for FCGI processes and FCGI::Engine seemed much more sane to me than C::E::FastCGI and FCGI::ProcManager. However, when attempting to create a script to launch an existing Catalyst app as FastCGI processes via FCGI::Engine I get the following strange behavior (Apache 2.2 w/ mod_fastcgi talking to Catalyst via console-launched external FastCGI socket): 1. Requests to Apache seem to connect and begin to get data but then hang and Apache's memory usage skyrockets. Is there a bad loop somewhere that's constantly writing to Apache? I can literally go back-and-forth b/t my old C::E::FastCGI script and my new FCGI::Engine script and the C::E::FastCGI version works fine. 2. The processes spawned via the FCGI::Engine script do not appear to honor SIGNALs. Again I can go back-and-forth b/t my old C::E::FastCGI script and the FCGI::Engine one and the latter does not respond to 'kill -TERM' only 'kill -KILL', while the processes created via the old-style script seem to work fine when sent a SIGTERM. ######### BEGIN FCGI::Engine based script #!/usr/bin/perl #BEGIN { # $ENV{CATALYST_ENGINE} ||= 'CGI'; #} use strict; use warnings; use FindBin; use lib( "$FindBin::Bin/../lib", "$FindBin::Bin/../ext-lib", ); use FCGI::Engine; #use My::Cat::App; FCGI::Engine->new_with_options( handler_class => 'My::Cat::App', handler_method => 'handle_request', )->run;
From: stevan.little [...] iinteractive.com
Download (untitled) / with headers
text/plain 2.4k
Matthew, Patches are very welcome. I have had issues with Catalyst, mod_perl and Apache where errors thrown by Cat are not trapped correctly and throw Apache into a loop which attempts to consume all the available memory. We tried several times to debug this without success (some of my coworkers are Core Cat developers too). Upgrading Catalyst seems to help this a little, along with some other really ugly hacks. However, this is probably not related to your issue, although it does sound kind of similar. However, this was before FCGI::Engine, and since then we have moved to Lighttpd from Apache. And to be completely honest, I didn't test this module much under Apache either since we don't use it much anymore. There are some slight differences between C::E::FastCGI and FCGI::Engine, mostly in how they are daemonized. This may be what is causing the problem, and might be a good place to start looking. - Stevan On Thu Mar 27 16:42:32 2008, invinity wrote: Show quoted text
> I'm interested in writing a patch to add better process management for > FCGI processes and FCGI::Engine seemed much more sane to me than > C::E::FastCGI and FCGI::ProcManager. > > However, when attempting to create a script to launch an existing > Catalyst app as FastCGI processes via FCGI::Engine I get the following > strange behavior (Apache 2.2 w/ mod_fastcgi talking to Catalyst via > console-launched external FastCGI socket): > > 1. Requests to Apache seem to connect and begin to get data but then > hang and Apache's memory usage skyrockets. Is there a bad loop somewhere > that's constantly writing to Apache? I can literally go back-and-forth > b/t my old C::E::FastCGI script and my new FCGI::Engine script and the > C::E::FastCGI version works fine. > > 2. The processes spawned via the FCGI::Engine script do not appear to > honor SIGNALs. Again I can go back-and-forth b/t my old C::E::FastCGI > script and the FCGI::Engine one and the latter does not respond to 'kill > -TERM' only 'kill -KILL', while the processes created via the old-style > script seem to work fine when sent a SIGTERM. > > > ######### BEGIN FCGI::Engine based script > > #!/usr/bin/perl > > #BEGIN { > # $ENV{CATALYST_ENGINE} ||= 'CGI'; > #} > > use strict; > use warnings; > > use FindBin; > use lib( > "$FindBin::Bin/../lib", > "$FindBin::Bin/../ext-lib", > ); > > use FCGI::Engine; > #use My::Cat::App; > > FCGI::Engine->new_with_options( > handler_class => 'My::Cat::App', > handler_method => 'handle_request', > )->run;
From: mpitts [...] a3its.com
Download (untitled) / with headers
text/plain 1.6k
On Thu Mar 27 21:35:22 2008, STEVAN wrote: Show quoted text
> Matthew, > > Patches are very welcome. > > I have had issues with Catalyst, mod_perl and Apache where errors > thrown by Cat are not trapped correctly and throw > Apache into a loop which attempts to consume all the available memory. > We tried several times to debug this without > success (some of my coworkers are Core Cat developers too). Upgrading > Catalyst seems to help this a little, along with > some other really ugly hacks. However, this is probably not related to > your issue, although it does sound kind of > similar. However, this was before FCGI::Engine, and since then we have > moved to Lighttpd from Apache. And to be > completely honest, I didn't test this module much under Apache either > since we don't use it much anymore. > > There are some slight differences between C::E::FastCGI and > FCGI::Engine, mostly in how they are daemonized. This > may be what is causing the problem, and might be a good place to start > looking.
Thanks for the quick response. Actually, it turned out to be the missing MyApp->write method from C::E::FastCGI. I assumed that by using FCGI::Engine, Catalyst wouldn't need to use C::E::FastCGI, but because Catalyst delegates $c->write to $c->engine->write the FastCGI compatible write method still needs to exist. I guess a solution to this would be to subclass FCGI::Engine in the C::Engine namespace, copy over the C::Engine::FastCGI->write method, and write the myapp_fastcgi.pl script as necessary. However, I doubt that the need for a FastCGI-compatiable write method is only a problem in the Catalyst world. Thoughts? v/r -matt pitts
From: stevan.little [...] iinteractive.com
Download (untitled) / with headers
text/plain 1.4k
Matthew, On Sat Mar 29 14:14:04 2008, invinity wrote: Show quoted text
> Actually, it turned out to be the missing MyApp->write method from > C::E::FastCGI. I assumed that by using FCGI::Engine, Catalyst wouldn't > need to use C::E::FastCGI, but because Catalyst delegates $c->write to > $c->engine->write the FastCGI compatible write method still needs to exist.
Ahh good catch! Show quoted text
> I guess a solution to this would be to subclass FCGI::Engine in the > C::Engine namespace, copy over the C::Engine::FastCGI->write method, and > write the myapp_fastcgi.pl script as necessary. However, I doubt that > the need for a FastCGI-compatiable write method is only a problem in the > Catalyst world.
Actually now that you talk about it and I looked over my Cat apps using FCGI::Engine I realize that I never replaced C::E::FastCGI with FCGI::Engine at the application level, but instead use the FCGI::Engine::Manager to manage my C::E::FastCGI apps. Really FCGI::Engine is only compatible with C::E::FastCGI in terms of it's command line API, not with it's API to Cat, sorry I should have been more explicit about that in the docs. I have planned to eventually write a Cat::Engine::FCGI::Engine, but I haven't found the time (or had the need fully yet). If you want to take a stab at it, please feel free. If you want to do this, probably best to take this conversation off RT and onto regular email, you can email me at my stevan@cpan.org address and we can discuss. THanks, - Stevan
Download (untitled) / with headers
text/plain 246b
I have added a note to the docs about usage with Catalyst in the latest release (0.04). Eventually it would be nice to have a Catalyst::Engine::FCGI::Engine, but the need is minimal so i think that docs will suffice for now. Thanks, - Stevan


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.