ruby’ists-
any of you out there using fcgi.{so,rb} ? i’m liking the speed, but several
issues remain which i have not, as of yet, groked :
- accessing parameters!
- doing a file upload via fcgi
- running from the command line for testing
- testing period (Web::Unit perhaps…)
- best methodology for shutting down/reloading script, there seems to be too
many ways to put apache into a bad state using fcgi’s
- memory management - how to return memory to the system? x = nil?
overall, this approach to web development seems simpler, faster, and safer
than just about any other approach while providing for scalability and
distributed web systems. however, it seems like there are still some small
issues to deal with to make this a really viable (read easy to use/develop)
solution). does anyone else have experiences they’d like to share? pointers?
any interest in improving the interface somewhat?
-a
···
–
====================================
Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================
My project group kept running into mysterious hangs with Apache’s
mod_fastcgi, and one of us wrote a slightly different module, mod_scgi
(Download MEMS & Nanotechnology Exchange Software Here). SCGI tries to keep things
simple, so Apache never starts an SCGI process for you. Instead, you run a
separate server process that can be started and stopped independently of
Apache. The advantages are that the mod_scgi C code is much simpler, the
SCGI protocol is simpler than the FastCGI protocol, and you can run the SCGI
server under any user ID and group ID you like.
Currently there’s only a Python SCGI client module, but a Ruby module would
certainly be added to the distribution, if anyone wants to write one.
–amk (www.amk.ca)
I’m as fit as a trombone.
– The Doctor, in “Time and the Rani”
···
On Mon, 10 Feb 2003 16:23:27 +0000, ahoward ahoward@fsl.noaa.gov wrote:
- best methodology for shutting down/reloading script, there seems to be too
many ways to put apache into a bad state using fcgi’s
- best methodology for shutting down/reloading script, there seems to be too
many ways to put apache into a bad state using fcgi’s
My project group kept running into mysterious hangs with Apache’s
mod_fastcgi,
can you elaborate? how were you managing signals?
and one of us wrote a slightly different module, mod_scgi
(http://www.mems-exchange.org/software/scgi/). SCGI tries to keep things
simple, so Apache never starts an SCGI process for you. Instead, you run a
separate server process that can be started and stopped independently of
Apache. The advantages are that the mod_scgi C code is much simpler, the
SCGI protocol is simpler than the FastCGI protocol, and you can run the SCGI
server under any user ID and group ID you like.
how is this different than simply using FastCgiExternalServer ?
Currently there’s only a Python SCGI client module, but a Ruby module would
certainly be added to the distribution, if anyone wants to write one.
i may be interested - if i could convince my boss to donate my time.
-a
···
On Mon, 10 Feb 2003, A.M. Kuchling wrote:
On Mon, 10 Feb 2003 16:23:27 +0000, > ahoward ahoward@fsl.noaa.gov wrote:
–amk (www.amk.ca)
I’m as fit as a trombone.
– The Doctor, in “Time and the Rani”
–
====================================
Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================
can you elaborate? how were you managing signals?
We don’t use signals at all (they’re evil!). The symptom was that all of
the FastCGI processes ceased to do any work. The probable cause was some
sort of deadlock, because if you killed the FastCGI process manager, which
forks off the worker processes, the workers began to accept requests again.
Unfortunately once you’ve done that, there’s no one to start new workers
once the old ones die.
how is this different than simply using FastCgiExternalServer ?
The protocol is still much, much simpler than the FastCGI protocol,
and therefore more likely to be implemented correctly.
–amk (www.amk.ca)
Can I have more water, please? My hair drank most of it.
– Lyta Hall, in SANDMAN #61: “The Kindly Ones:5”
···
On Mon, 10 Feb 2003 17:56:29 +0000, ahoward ahoward@fsl.noaa.gov wrote:
can you elaborate? how were you managing signals?
We don’t use signals at all (they’re evil!). The symptom was that all of
the FastCGI processes ceased to do any work. The probable cause was some
sort of deadlock, because if you killed the FastCGI process manager, which
forks off the worker processes, the workers began to accept requests again.
Unfortunately once you’ve done that, there’s no one to start new workers
once the old ones die.
it looks like the fcgi_pm forwards TERM on to all it’s children, so unless the
chose to ignore it, they should also exit when it is killed. if this does not
work the pm sends SIGKILL to all the children, whcih ought to do it. however,
i could see how things might get messy if you sent SIGKILL to the fcgi_pm
process itself… however ‘kill -9’ must be expected to be messy in any
case…
the problem i see is that i cannot seem to get applications to reload properly
: i catch SIGHUP and SIGTERM and send SIGCHLD to my Process.ppid and then
exit. this DOES cause the application to exit, and therefore be restarted,
but only on the SECOND invocation of the page - eg the first one results in
internal server error and only the second one seems to actually have restarted
the process… any experience with this?
how is this different than simply using FastCgiExternalServer ?
The protocol is still much, much simpler than the FastCGI protocol,
and therefore more likely to be implemented correctly.
yes it does look simpler. i will look at the python module to see about
porting it to ruby…
i do like the automatic restart of applications under fastcgi, but that
would be pretty easy to setup…
-a
···
On Mon, 10 Feb 2003, A.M. Kuchling wrote:
On Mon, 10 Feb 2003 17:56:29 +0000, > ahoward ahoward@fsl.noaa.gov wrote:
–amk (www.amk.ca)
Can I have more water, please? My hair drank most of it.
– Lyta Hall, in SANDMAN #61: “The Kindly Ones:5”
–
====================================
Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================