Given this controller:
------------------------------------
require ''open-uri''
class HangController < ApplicationController
def m1
@content = open(''http://localhost:3000/hang/m2'') do |s|
s.read
end
end
def m2
end
end
------------------------------------------------
I know there are probably a million reasons not to be doing something
like this, but I was just wondering why. This happens using webrick
as well as running using lighttpd/fastcgi.
TIA,
Doug Seifert
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Hi, Doug wrote:> class HangController < ApplicationController > > def m1 > @content = open(''http://localhost:3000/hang/m2'') do |s| > s.read > end > end > > def m2 > end > endRoR is not multithreaded so in your setup the call to /hang/m2 can''t be answered before the call to /hang/m2 returned which waits for /hang/ms to return ... Lutz -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > RoR is not multithreaded so in your setup the call to /hang/m2 can''t be > answered before the call to /hang/m2 returned which waits for /hang/ms > to return ...Thanks for the reply. I realize that ROR is not multi-threaded and that would explain why it hangs in the webrick case. I guess if lighttpd is routing the second request to the same fastcgi instance, that would explain why it hangs in that environment as well. But why would lighttpd do that? Anyway, this is more out of curiosity than anything else. I know in general this type of thing won''t work. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 29 Oct 2007, at 17:32, Doug wrote:> >> >> RoR is not multithreaded so in your setup the call to /hang/m2 >> can''t be >> answered before the call to /hang/m2 returned which waits for / >> hang/ms >> to return ... > > Thanks for the reply. I realize that ROR is not multi-threaded and > that would explain why it hangs in the webrick case. I guess if > lighttpd is routing the second request to the same fastcgi instance, > that would explain why it hangs in that environment as well. But why > would lighttpd do that? > > Anyway, this is more out of curiosity than anything else. I know in > general this type of thing won''t work. > >I don''t know about lighttpd but a lot of load balancers seem to assume that the thing that they''re balancing to is multithreaded, so that it doesn''t matter if they queue more than one request to the same worker (as long as on average everyone gets the right amount of work. It may also be configured not to spawn more than a certain number of instances, it wouldn''t surprise me if that number was 1 in dev mode. Fred --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> I don''t know about lighttpd but a lot of load balancers seem to > assume that the thing that they''re balancing to is multithreaded, so > that it doesn''t matter if they queue more than one request to the > same worker (as long as on average everyone gets the right amount of > work. It may also be configured not to spawn more than a certain > number of instances, it wouldn''t surprise me if that number was 1 in > dev mode.Ignore anything I said about lighttpd/fastcgi. It works ok in that environment. The m2 request gets routed to another fastcgi process and the whole thing works. It would probably hang/time out if all fastcgi processes were doing the secondary request at the same time, however. Thanks for everybody''s comments. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---