What''s the impact of switching from mongrels to mod_rails with respect to the ability to support long-running processes within a Rails app, as opposed to the current situation where they''re best moved off to a distributed process? Thanks, Bill --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Apr 20, 2008, at 9:59 AM, Bill Walton wrote:> What''s the impact of switching from mongrels to mod_rails with > respect to the ability to support long-running processes within a > Rails app, as opposed to the current situation where they''re best > moved off to a distributed process? > > Thanks, > BillThat situation doesn''t change, you still need to separate out long requests. Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- ezra-NLltGlunAUd/unjJdyJNww@public.gmane.org -- EngineYard.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 -~----------~----~----~----~------~----~------~--~---
On 20 Apr 2008, at 19:48, Ezra Zygmuntowicz wrote:> > > On Apr 20, 2008, at 9:59 AM, Bill Walton wrote: >> What''s the impact of switching from mongrels to mod_rails with >> respect to the ability to support long-running processes within a >> Rails app, as opposed to the current situation where they''re best >> moved off to a distributed process? >> >> Thanks, >> Bill > > > That situation doesn''t change, you still need to separate out long > requests.And even if mod_rails did change that, it would still be poor user experience to have the user just starting at their browser''s load bar without any progress information (or information that anything at all is happening). 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 -~----------~----~----~----~------~----~------~--~---
Ezra Zygmuntowicz wrote:> > On Apr 20, 2008, at 9:59 AM, Bill Walton wrote: > > What''s the impact of switching from mongrels to mod_rails with > > respect to the ability to support long-running processes within a > > Rails app, as opposed to the current situation where they''re best > > moved off to a distributed process? > > > > That situation doesn''t change, you still need to separate out long > requests.Thanks, Ezra. I realize this doesn''t change the fundamentals of Rails, but was hoping it might open some new avenues. We''ve got a user-initiated file-upload-and-process process that gets used maybe 3 or 4 times a month. The current config (mongrel cluster managed by haproxy) throws a proxy error for any process that takes more than 30 seconds to complete under the assumption that a mongrel has become unresponsive. This process takes considerably more than 30 seconds so the user sees an error page even though the process completes successfully. We''re reluctant to eliminate the haproxy timeout because the mongrels do need to be managed. Our infrastructure support team is new to Rails (and LAMP) and so we''re reluctant to insert distributed processes into the mix at this point. So... suggestions ? Thanks, Bill --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Craig White
2008-Apr-21 14:29 UTC
Re: ****[Rails] Re: mod_rails and long-running processes
On Mon, 2008-04-21 at 07:17 -0500, Bill Walton wrote:> Ezra Zygmuntowicz wrote: > > > > On Apr 20, 2008, at 9:59 AM, Bill Walton wrote: > > > What''s the impact of switching from mongrels to mod_rails with > > > respect to the ability to support long-running processes within a > > > Rails app, as opposed to the current situation where they''re best > > > moved off to a distributed process? > > > > > > > That situation doesn''t change, you still need to separate out long > > requests. > > Thanks, Ezra. I realize this doesn''t change the fundamentals of Rails, but > was hoping it might open some new avenues. We''ve got a user-initiated > file-upload-and-process process that gets used maybe 3 or 4 times a month. > The current config (mongrel cluster managed by haproxy) throws a proxy error > for any process that takes more than 30 seconds to complete under the > assumption that a mongrel has become unresponsive. This process takes > considerably more than 30 seconds so the user sees an error page even though > the process completes successfully. We''re reluctant to eliminate the > haproxy timeout because the mongrels do need to be managed. Our > infrastructure support team is new to Rails (and LAMP) and so we''re > reluctant to insert distributed processes into the mix at this point. So... > > suggestions ?---- backgroundrb plugin that''s what it was created for Craig --~--~---------~--~----~------------~-------~--~----~ 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 Apr 21, 2008, at 5:17 AM, Bill Walton wrote:> > Ezra Zygmuntowicz wrote: >> >> On Apr 20, 2008, at 9:59 AM, Bill Walton wrote: >>> What''s the impact of switching from mongrels to mod_rails with >>> respect to the ability to support long-running processes within a >>> Rails app, as opposed to the current situation where they''re best >>> moved off to a distributed process? >>> >> >> That situation doesn''t change, you still need to separate out long >> requests. > > Thanks, Ezra. I realize this doesn''t change the fundamentals of > Rails, but > was hoping it might open some new avenues. We''ve got a user-initiated > file-upload-and-process process that gets used maybe 3 or 4 times a > month. > The current config (mongrel cluster managed by haproxy) throws a > proxy error > for any process that takes more than 30 seconds to complete under the > assumption that a mongrel has become unresponsive. This process takes > considerably more than 30 seconds so the user sees an error page > even though > the process completes successfully. We''re reluctant to eliminate the > haproxy timeout because the mongrels do need to be managed. Our > infrastructure support team is new to Rails (and LAMP) and so we''re > reluctant to insert distributed processes into the mix at this > point. So... > > suggestions ? > > Thanks, > BillYou are either going to have to break out a background process of some sort or you are going to need to increase the haproxy timeout to a large enough value for the long task to complete. No magical way around it, it''s one of these two paths that you have to take. Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- ezra-NLltGlunAUd/unjJdyJNww@public.gmane.org -- EngineYard.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 -~----------~----~----~----~------~----~------~--~---