[Backgroundrb-devel] [ANN] BackgrounDRb 0.2.0 Release! Complete rewrite.

skaar skaar at waste.org
Mon Oct 30 18:32:32 EST 2006

> I'm using slave 0.2.0 in my application right now. I'm using it to  
> run some potentially very long running processes. In my case, it  
> doesn't really matter if they fail, but if they do I'd like know  
> about it so I can tell the user and possibly re-start them. At the  
> moment if that scenario occurs then I can only tell by a time out. If  
> I wasn't so lazy I could do something smarter, like mark the fact  
> that the process is running somewhere in the DB (which might really  
> be the filesystem), maybe with a pid. When I check on progress I can  
> see if slave/backgroundrb has any knowledge of that process, if it  
> doesn't then I can assume that the server failed and as re-started.  
> If slave/backgroundrb knows of the process but the process no longer  
> exists then I can assume that it failed in an unpleasant way.

the crude way of doing this right now is to use a singleton/named worker
- and call new_worker(:class => :foo_worker, :job_key => :job_name)
every time you access it. If the worker exist, you will just get the key
back, if it doesn't the server will create the worker, and then return
the key.

You can the same way, with generated keys, on the client side initially
call new_worker without the :job_key argument and store the key - if you
next time have a key, you can call new_worker with the job_key that was
generated for you and that you, say, have stored in the users session.


|\|\             where in the       |          s_u_b_s_t_r_u_c_t_i_o_n 
| | >===========  W.A.S.T.E.        |                  genarratologies 
|/|/    (_)     is the wisdom       |                  skaar at waste.org

More information about the Backgroundrb-devel mailing list