Rails - Dec 2010 - managing a lengthy process with periodic page updates

In my application, there''s a point where a user will initiate an action
that will take a LONG time to complete.  (Among other things, it needs
to dynamically gather data from a number of external sources.)  Rather
than simply leaving the user hanging while waiting for a response, I''d
like to give feedback at various steps during the process.

My first instinct is to spawn a thread to run the process, and use a
carefully managed interface to provide updates.  But I suspect that may
not work the way I expect -- it really depends on the lifecycle of
ActionPack transactions, no?  (For example, would I need do a join
somewhere to keep the owning process alive long enough for the thread to
complete?)

Regardless, this must be design problem that''s been solved several
times
over.  What''s considered best practices in Rails, and where can I learn
more about how to implement it?

TIA.

- ff

[*] OTOH, I''m experienced in multi-threaded design, just not in RoR.

-- 
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-/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.

On Dec 8, 11:35 am, Fearless Fool
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org>
wrote:
> My first instinct is to spawn a thread to run the process, and use a
> carefully managed interface to provide updates.  But I suspect that may
> not work the way I expect -- it really depends on the lifecycle of
> ActionPack transactions, no?  (For example, would I need do a join
> somewhere to keep the owning process alive long enough for the thread to
> complete?)
>
Look at something like delayed_job..

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-/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.

On 08 Dec 2010, at 13:37, Frederick Cheung wrote:
> On Dec 8, 11:35 am, Fearless Fool
<li...-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:
>> My first instinct is to spawn a thread to run the process, and use a
>> carefully managed interface to provide updates.  But I suspect that  
>> may
>> not work the way I expect -- it really depends on the lifecycle of
>> ActionPack transactions, no?  (For example, would I need do a join
>> somewhere to keep the owning process alive long enough for the  
>> thread to
>> complete?)
>>
> Look at something like delayed_job..
Or Nanite combined with Redis for the progress feedback.

Also, instead of using a periodical updater you could look into a push  
server (and event-based server like Node.js to send the events on the  
server, some websockets+fallback script on the client side).


Best regards

Peter De Berdt

-- 
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.