Hi, I found this article http://cyll.org/blog/tech/2006-08-09-themongrelcomet.html on mongrel and COMET very interesting. I ran the code, and it worked just as Christopher explained. The one thing I don''t understand is why mongrel can only handle 1 connection at a time. I thought that mongrel used a thread per connection. It appears that each registered handler can only handle 1 connection. So if a request comes into another handler, it will be handled. My question is: Is there a way to allow a single handler to serve multple connections? I''m going to try debugging this to see why the handler is blocked, but if someone knows the answer before I find out, please shout it out. thanks, -joe
On 12/5/06, Joseph McDonald <superjoe at gmail.com> wrote:> Hi, > > I found this article > http://cyll.org/blog/tech/2006-08-09-themongrelcomet.html on mongrel > and COMET very interesting. > > I ran the code, and it worked just as Christopher explained. The one > thing I don''t understand is why mongrel can only handle 1 connection > at a time. I thought that mongrel used a thread per connection. >Let me correct you on this: Mongrel CAN handle multiple incoming connections, Rails can''t. Rails is not thread-safe, mongrel is. So: using mongrel with rails (ala, mongrel_rails command line util) will put a lock around Rails dispatcher to avoid issues with ActiveRecord.> It appears that each registered handler can only handle 1 connection. > So if a request comes into another handler, it will be handled. >Thats RailsHandler, other frameworks (AFAIK, IOWA, MERB) are thread safe in that aspect.> My question is: Is there a way to allow a single handler to serve > multple connections? > > I''m going to try debugging this to see why the handler is blocked, but > if someone knows the answer before I find out, please shout it out. >Besides issue with the use of select() by ruby, also the use of green(ala fake) threads instead of native ones... guess there is not much help on this area. Please, If I''m wrong in some of the things I have said, don''t start a flamewar, just point me in the right direction and correct my ignorance :-) -- Luis Lavena Multimedia systems - Leaders are made, they are not born. They are made by hard effort, which is the price which all of us must pay to achieve any goal that is worthwhile. Vince Lombardi
On 12/5/06, Joseph McDonald <superjoe at gmail.com> wrote:> > I ran the code, and it worked just as Christopher explained. The one > thing I don''t understand is why mongrel can only handle 1 connection > at a time. I thought that mongrel used a thread per connection.The simple answer: Mongrel is multithreaded, but Rails is not thread-safe. See question two in the FAQ: http://mongrel.rubyforge.org/faq.html /David -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20061205/7da2a2ed/attachment.html
I understand that rails is not thread safe, but this is not using rails or any part of rails. It just sets up a simple handler. but registering that handler seems to allow only one instance of that handler to run at a time. On 12/5/06, David Vrensk <david at vrensk.com> wrote:> On 12/5/06, Joseph McDonald <superjoe at gmail.com> wrote: > > I ran the code, and it worked just as Christopher explained. The one > > thing I don''t understand is why mongrel can only handle 1 connection > > at a time. I thought that mongrel used a thread per connection. > > > The simple answer: Mongrel is multithreaded, but Rails is not thread-safe. > See question two in the FAQ: > http://mongrel.rubyforge.org/faq.html > > /David > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > >
If you read that wikipedia article, you''ll note that Comet actually does want this to happen: one connection to be kept alive. Mongrel afai understand it is not meant to be used with keep-alive-ish sort of connections. Polling (via AJAX) would more often than not serve your purpose, and if it doesn''t, a switch to Java or Cometd seems to be the way to go. Vish On 12/6/06, Joseph McDonald <superjoe at gmail.com> wrote:> > I understand that rails is not thread safe, but this is not using > rails or any part of rails. It just sets up a simple handler. but > registering that handler seems to allow only one instance of that > handler to run at a time. > > > On 12/5/06, David Vrensk <david at vrensk.com> wrote: > > On 12/5/06, Joseph McDonald <superjoe at gmail.com> wrote: > > > I ran the code, and it worked just as Christopher explained. The one > > > thing I don''t understand is why mongrel can only handle 1 connection > > > at a time. I thought that mongrel used a thread per connection. > > > > > > The simple answer: Mongrel is multithreaded, but Rails is not > thread-safe. > > See question two in the FAQ: > > http://mongrel.rubyforge.org/faq.html > > > > /David > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/mongrel-users/attachments/20061206/a220b9df/attachment.html
OK. I''m just trying to understand why/where mongrel is blocking when more than 1 request comes in for a particular uri. I''m thinking there may be something different with this particular httphandler. Or maybe not... maybe mongrel can''t service more than 1 request for a particular uri at a time. It''s interesting that more than 1 can run at a time, you just need to associate them with different uri''s. I''d like to find out why that is, and if that''s changeable. -joe On 12/5/06, Vishnu Gopal <g.vishnu at gmail.com> wrote:> If you read that wikipedia article, you''ll note that Comet actually does > want this to happen: one connection to be kept alive. Mongrel afai > understand it is not meant to be used with keep-alive-ish sort of > connections. Polling (via AJAX) would more often than not serve your > purpose, and if it doesn''t, a switch to Java or Cometd seems to be the way > to go. > > Vish > > > On 12/6/06, Joseph McDonald <superjoe at gmail.com> wrote: > > I understand that rails is not thread safe, but this is not using > > rails or any part of rails. It just sets up a simple handler. but > > registering that handler seems to allow only one instance of that > > handler to run at a time. > > > > > > On 12/5/06, David Vrensk <david at vrensk.com> wrote: > > > On 12/5/06, Joseph McDonald <superjoe at gmail.com> wrote: > > > > I ran the code, and it worked just as Christopher explained. The one > > > > thing I don''t understand is why mongrel can only handle 1 connection > > > > at a time. I thought that mongrel used a thread per connection. > > > > > > > > > The simple answer: Mongrel is multithreaded, but Rails is not > thread-safe. > > > See question two in the FAQ: > > > http://mongrel.rubyforge.org/faq.html > > > > > > /David > > > > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > _______________________________________________ > Mongrel-users mailing list > Mongrel-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mongrel-users > >
well i think i found the problem... I think it''s my browser. I could not open more than 1 connection with firefox, but if i opened msie and opera on the url, the data came streaming on down simultaneously. sorry for the false alarm! -joe On 12/5/06, Joseph McDonald <superjoe at gmail.com> wrote:> OK. I''m just trying to understand why/where mongrel is blocking when > more than 1 request comes in for a particular uri. I''m thinking there > may be something different with this particular httphandler. Or maybe > not... maybe mongrel can''t service more than 1 request for a > particular uri at a time. > > It''s interesting that more than 1 can run at a time, you just need to > associate them with different uri''s. I''d like to find out why that > is, and if that''s changeable. > > -joe > > On 12/5/06, Vishnu Gopal <g.vishnu at gmail.com> wrote: > > If you read that wikipedia article, you''ll note that Comet actually does > > want this to happen: one connection to be kept alive. Mongrel afai > > understand it is not meant to be used with keep-alive-ish sort of > > connections. Polling (via AJAX) would more often than not serve your > > purpose, and if it doesn''t, a switch to Java or Cometd seems to be the way > > to go. > > > > Vish > > > > > > On 12/6/06, Joseph McDonald <superjoe at gmail.com> wrote: > > > I understand that rails is not thread safe, but this is not using > > > rails or any part of rails. It just sets up a simple handler. but > > > registering that handler seems to allow only one instance of that > > > handler to run at a time. > > > > > > > > > On 12/5/06, David Vrensk <david at vrensk.com> wrote: > > > > On 12/5/06, Joseph McDonald <superjoe at gmail.com> wrote: > > > > > I ran the code, and it worked just as Christopher explained. The one > > > > > thing I don''t understand is why mongrel can only handle 1 connection > > > > > at a time. I thought that mongrel used a thread per connection. > > > > > > > > > > > > The simple answer: Mongrel is multithreaded, but Rails is not > > thread-safe. > > > > See question two in the FAQ: > > > > http://mongrel.rubyforge.org/faq.html > > > > > > > > /David > > > > > > > > _______________________________________________ > > > > Mongrel-users mailing list > > > > Mongrel-users at rubyforge.org > > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > > > _______________________________________________ > > > Mongrel-users mailing list > > > Mongrel-users at rubyforge.org > > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > > > > > > _______________________________________________ > > Mongrel-users mailing list > > Mongrel-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/mongrel-users > > > > >
On Tue, 5 Dec 2006 13:08:14 -0800 "Joseph McDonald" <superjoe at gmail.com> wrote:> I understand that rails is not thread safe, but this is not using > rails or any part of rails. It just sets up a simple handler. but > registering that handler seems to allow only one instance of that > handler to run at a time.I think part of your confusion (and others) is the association of HttpHandlers with HttpRequests and HttpResponses. Also, how they''re run in the life cycle of a Mongrel HTTP request process. First, Mongrel accepts remote clients and creates one Thread for each request. Mongrel also enforces a single request/response using Connect:close headers because Ruby only supports 1024 files (so far). If Mongrel doesn''t do this then people like yourself can write a simple "trickle attack" client that hits the Mongrel server, opens a bunch of continuous connections, and then eat up all available files very quickly. Basically, a DDoS attack that''s very simple to do. So, keep that in mind with your comet thing. You''ll have to also keep track of the number of active connections and start getting into old school capacity planning to figure out how many mongrel processes are needed to service your appropriate user load. Second thing is that you can register multiple HttpHandler objects with a URIClassifier at a URL path, but that each one is run in sequence and they are run across all the threads. This means that *you* have to keep the threading straight in your HttpHandler since that same object''s state could be used by 500+ threads at once. This is also why each handler''s process(req,resp) method is given all the stuff it needs in the parameters. For example, this is *really* bad: class DumbAssHandler < HttpHandler def initialize() @afile = open("somefile.txt") end def process(req, response) @afile.write(req.params["X-Someheader"]) end end The problem is a *single* instance of DumbAssHandler is shared amongst *ALL* the threads that call DumbAssHandler::process(). When you start writing to @afile it''ll get all nasty and confused on you, but what''s worse is Ruby''s threading isn''t so clear on this so it *might* work most of the time, and then one day you hit that magic thread or switch to Linux and all hell breaks loose. Finally, each client processing Thread gets its very own HttpRequest and HttpResponse object, so within the process() method you can go to town on it without worrying about locking problems. If you need to store stuff someplace so that it''s not shared then just toss it into the req.params[] as a symbol with a funky name. You can also use Thread.current[] to store things, but there''s a hidden danger: The GC doesn''t run on Threads very often and not the same as other stuff, so things in Thread.current[] tend to live for longer than you expect. Anyway, hope that helps you out. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.