[Backgroundrb-devel] can a worker commit suicide?

skaar skaar at waste.org
Tue Oct 24 16:00:00 EDT 2006


Not that it will help you immediately, but the new BackgrounDRb should
not have this deadlock issue. Workers are separæte processes and the
do_work thread is local to this process. The process object itself
(using the slave library) is available to the worker and through that
you can call delete_worker on the MiddleMan, which has it's own thread
pool.

You don't have to do this yourself. The worker superclasses already have
a delete method which does this:

 class SelfDestructingWorker < BackgrounDRb::Worker::Base                                
   def do_work(args)                                                                     
     sleep 20                                                                            
     self.delete                                                                         
   end                                                                                   
 end                                                                                     

called through the MiddleMan, it looks something like:

  MiddleMan.new_worker :class => :self_destructing_worker, 
    :job_key => :self_destruct
   
Another behavior that should be noted, is that workers have a singleton
behavior in that:

  2000.times do
    MiddleMan.new_worker :class => :self_destructing_worker,
    :job_key => :self_destruct
  end

would return the same worker reference, until delete is called, when a
new worker would be created and the cycle started over again.

/skaar


* Ryan Garver (ragarver at gmail.com) [061024 13:00]:
> It appears that this method of committing suicide, if called from  
> within the do_work method appears to result in dead lock.  Which  
> makes sense since most of the operations on workers block on a mutex  
> including delete_worker.  I am curious about this because I am using  
> backgroundrb for periodic scheduling where most of the time (in my  
> case all of the time) they will not have an external monitor to clean  
> them up.  I'm hesitant to use ttls because some of the operations may  
> take a long time.  Any suggestions
> 
> - Ryan
> 
> On Oct 23, 2006, at 5:26 PM, Erik Morton wrote:
> 
> > I recommend closing the connection on the ActiveRecord instance in
> > the worker. In past versions of BackgroundRB those connections were
> > never closed. To check on open connections execute show processlist;
> >
> >
> > On Oct 23, 2006, at 6:20 PM, Bill Walton wrote:
> >
> >> Thank you, Michael.  I'm only disconnecting that particular worker,
> >> right?  It looks like it, since I can restart the app (browse to it
> >> again) and everything looks to work ok.  But I thought I'd ask.
> >> Also, is there any way to tell how many workers are running?  I'm
> >> on Windows XP and all I can see with Task Mgr. is a ruby.exe
> >> process for BackgrounDRb.
> >>
> >> Thanks again,
> >> Bill
> >> ----- Original Message -----
> >> From: Michael D'Auria
> >> To: Bill Walton
> >> Cc: Eden Li ; BackgroundRb
> >> Sent: Monday, October 23, 2006 3:28 PM
> >> Subject: Re: [Backgroundrb-devel] can a worker commit suicide?
> >>
> >> You can have the worker delete itself, just make sure you call
> >> ActiveRecord::Base.connection.disconect! first:
> >>
> >> ActiveRecord::Base.connection.disconect!
> >> ::BackgrounDRb::MiddleMan.instance.delete_worker @_job_key
> >>
> >> That shoudl ensure the db connection has been closed and delete the
> >> instance of the current worker
> >>
> >>
> >> On 10/23/06, Bill Walton <bill.walton at charter.net> wrote: Hi Eden,
> >>
> >> Eden Li wrote:
> >>
> >>> ... you can specify a :ttl(time to live) in seconds and your
> >> worker will
> >>> get killed after those seconds run out.
> >>
> >> I'm using BackgrounDRb to monitor session activity and deleting
> >> user entered
> >> data in the database when their session times out.  Every time  
> >> they do
> >> something, their time-til-timeout gets reset.  There's no notion of
> >> a max
> >> time.  As long as they keep using the app, their session stays alive.
> >>
> >> I was wondering if there's a way, inside the worker, to do the
> >> equivalent
> >> of:
> >> MiddleMan.delete_worker(session[:job_key])
> >>
> >> Thanks,
> >> Bill
> >> _______________________________________________
> >> Backgroundrb-devel mailing list
> >> Backgroundrb-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >>
> >> _______________________________________________
> >> Backgroundrb-devel mailing list
> >> Backgroundrb-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> >
> > _______________________________________________
> > Backgroundrb-devel mailing list
> > Backgroundrb-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/backgroundrb-devel
> 
> _______________________________________________
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel

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