Rails - Nov 2009 - Can the http response and the controller/action finish be separated?

Hi all,

I have a situation where a very simple request can trigger a time-
consuming operation, but the requesting page doesn''t need the result
of the lengthy computation.  In the standard controller action of
handling the http request, it appears that ack''ing the request is
closely coupled with completing the request.  Can this be altered in
order to separate these two actions in time?

Presumably, the return of the ack frees the browser and allows the
user to continue doing whatever.  However, what condition causes the
web server to send another request to this same rails instance?  What
would happen if the ack was sent, freeing the browser, but the rails
app kept crunching on the data?  How does the web server know when the
rails app is done?  Does the rails app get called like a proc and just
return to the web server?

I know that this answer will vary based on whether the web server is
Apache or mongrel or thin or nginx, but I would like to understand how
the controller code wraps up an action.

Can someone point me towards a writeup somewhere?

--

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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Hi,

You might want to have a look at the delayed_job gem (tobi built the
original, and it has since been forked and extended by a number of
people; I''d recommend collectiveidea''s version:
http://github.com/collectiveidea/delayed_job),
which handles lengthy operations (jobs) without the browser having to
sit around and wait for it to finish. See the doc for how it works.

The downside is that since the job will be running in the background,
the browser will be completely oblivious to it and its status. To work
around this, if you want to give the users some kind of overview, you
can always build a screen which checks the status or statuses of
running jobs.

delayed_job is server-side only, so in theory it shouldn''t matter
which webserver you''re using to serve the website with (Apache/mongrel/
nginx/etc.).

Best regards,
Sebastian

On Nov 27, 7:12 am, explainer
<keburg...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hi all,
>
> I have a situation where a very simple request can trigger a time-
> consuming operation, but the requesting page doesn''t need the
result
> of the lengthy computation.  In the standard controller action of
> handling the http request, it appears that ack''ing the request is
> closely coupled with completing the request.  Can this be altered in
> order to separate these two actions in time?
>
> Presumably, the return of the ack frees the browser and allows the
> user to continue doing whatever.  However, what condition causes the
> web server to send another request to this same rails instance?  What
> would happen if the ack was sent, freeing the browser, but the rails
> app kept crunching on the data?  How does the web server know when the
> rails app is done?  Does the rails app get called like a proc and just
> return to the web server?
>
> I know that this answer will vary based on whether the web server is
> Apache or mongrel or thin or nginx, but I would like to understand how
> the controller code wraps up an action.
>
> Can someone point me towards a writeup somewhere?
--

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-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@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.