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.
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 Shaw 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.-- Posted via http://www.ruby-forum.com/.
List Recv 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 :-)> 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? -- Alex
On Jan 31, 2006, at 5:11 AM, List Recv 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 http://www.kegel.com/c10k.html 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 http://www.zedshaw.com/
Heh, if we could only get Doug Lea hooked on Ruby.... b PS: if you don''t know who he is, google it... Zed Shaw wrote:> > On Jan 31, 2006, at 5:11 AM, List Recv 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 http://www.kegel.com/c10k.html 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 > http://www.zedshaw.com/ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
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 ;) Duane Johnson (canadaduane) http://blog.inquirylabs.com/ On Jan 31, 2006, at 5:08 AM, Zed Shaw wrote:> > On Jan 31, 2006, at 5:11 AM, List Recv 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 http://www.kegel.com/c10k.html 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 > http://www.zedshaw.com/ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails