[ANN] SCGI Rails Runner RubyForge Project

Hello Rails Folks,

This is just a quick announcement to let people know that SCGI Rails
Runner now has a RubyForge project at:

http://rubyforge.org/projects/scgi/

There’s already a few bug and feature requests there and I’ll be
quickly putting more docs online as well as a new release shortly.
The latest source is checked into subversion if you are interested in
tracking it closely.

Feel free to put all your bugs and features into the Tracker. You
can also subscribe to the mailing list and post any FAQs to the
forums. I’m also open to advice on how to run the RubyForge project.

Thanks for your time.

Zed A. Shaw

P.S. My time will be split between SCGI and Mongrel (http://
rubyforge.org/projects/mongrel/) until they can both run Rails in a
stable fashion. Debate over the relative merit of both is welcome.

Zed’s SCGI Runner (SRR) is committed to using Ruby threads, not
processes or even native OS threads.

This means it will never have the stability and robustness large
scale, critical apps need.

A misbehaving thread can bring the whole thing down. It can lock up and
keep the whole system locked. A long syscall can paralyze everything.
I’ve tried the SRR (can’t beat it’s simplicity or coolness!), but had to
give it up due to this problem.

Zed S. wrote:

Hello Rails Folks,

This is just a quick announcement to let people know that SCGI Rails
Runner now has a RubyForge project at:

http://rubyforge.org/projects/scgi/

There’s already a few bug and feature requests there and I’ll be
quickly putting more docs online as well as a new release shortly.
The latest source is checked into subversion if you are interested in
tracking it closely.

Feel free to put all your bugs and features into the Tracker. You
can also subscribe to the mailing list and post any FAQs to the
forums. I’m also open to advice on how to run the RubyForge project.

Thanks for your time.

Zed A. Shaw
http://www.zedshaw.com/

P.S. My time will be split between SCGI and Mongrel (http://
rubyforge.org/projects/mongrel/) until they can both run Rails in a
stable fashion. Debate over the relative merit of both is welcome.

List R. wrote:

This means it will never have the stability and robustness large
scale, critical apps need.
Yes it can. Robustness can be built in through redundancy, which is
precisely what the Rails shared-nothing model allows, and which allows
scaling in the first place.

A misbehaving thread can bring the whole thing down. It can lock up and
keep the whole system locked.
And you can DOS a Linux box with a dodgy malloc(). And yet, somehow,
the universe has yet to come crashing down :slight_smile:

I’ve tried the SRR (can’t beat it’s simplicity or coolness!), but had to
give it up due to this problem.
I can’t fault your opinion, I can only say that mine differs. Have you
got a failing case that can be replicated?

On Jan 31, 2006, at 5:11 AM, List R. wrote:

Zed’s SCGI Runner (SRR) is committed to using Ruby threads, not
processes or even native OS threads.

Yes, this is true but there’s not much other choice. Sad fact is
that even Ruby’s own IO.select has problem with Ruby’s own
threads. Apart from using a special build of Ruby that has native
threads there isn’t much you can do.

Incidentally, you should read The C10K problem to
understand why processes and threads don’t give you performance.

This means it will never have the stability and robustness large
scale, critical apps need.

Never is a pretty strong word, but I will say you should look at my
other project in the works called Mongrel (http://rubyforge.org/
projects/mongrel/) for clues to the next release of SCGI.

A misbehaving thread can bring the whole thing down. It can lock
up and
keep the whole system locked. A long syscall can paralyze everything.
I’ve tried the SRR (can’t beat it’s simplicity or coolness!), but
had to
give it up due to this problem.

This is true as well. If you write code that makes a thread
misbehave then you are screwed. It is easy to avoid the problem by
simply making sure that you clean up all your created resources when
your controller action finishes–which is what you should be doing
anyway. That being said it’s a pretty big change for some people to
make since it requires understanding how their resources should be
managed. The next release may try to help people out with this, but
I’m also afraid this will make SRR more complex.

BTW, I’d love a small sample snippet of code which demonstrates this
problem. I’ve had maybe 3 people complain about this yet none of
them could give me a piece of sample code which replicated the
problem. It’s really driving me insane.

Zed A. Shaw

Heh, if we could only get Doug Lea hooked on Ruby…

b

PS: if you don’t know who he is, google it…

Nice work, Zed. Thanks for keeping SCGI on the railroad of
progress. I didn’t doubt for a minute that your mad skillz had left
the building :wink:

Duane J.
(canadaduane)
http://blog.inquirylabs.com/