mod_rails and long-running processes

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.

Cheers-

- Ezra Zygmuntowicz -- Founder & Software Architect -- ezra@engineyard.com -- EngineYard.com

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

Ezra Zygmuntowicz 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

Ezra Zygmuntowicz 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 ?

You 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@engineyard.com -- EngineYard.com