Can a worker kill themselves when they''re ''done''? Or do I have to do that either from the controller or the worker manager? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061023/11dd429c/attachment.html
You can specify a time to live in the args to MiddleMan.new_worker.>From the README http://backgroundrb.rubyforge.org/:... you can specify a :ttl(time to live) in seconds and your worker will get killed after those seconds run out. The following will start a FooWorker class with a text argument of "Bar" and a time to live of 5 minutes session[:job_key] = MiddleMan.new_worker(:class => :foo_worker, :args => "Bar", :ttl => 300) On 10/24/06, Bill Walton <bill.walton at charter.net> wrote:> Can a worker kill themselves when they''re ''done''? Or do I have to do that > either from the controller or the worker manager?
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
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061023/4d850c67/attachment.html
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20061023/7fda71ff/attachment.html
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
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
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
----------------------------------------------------------------------
Erik, I''m running with svn:externals off of rubyforge. The disconnecting of the db actually works well. But as soon as I called the self.kill or terminate it froze. This may not be deadlock, but I was finding the server unreachable with very little information about why on stdout (this is _not_ in detached mode). As it turns out this may bee a moot issue since the worker is acting as a singleton (apparently) as a periodic job. This may be wrong, but thats what I''ve pieced together between the source and the mailing list. On Oct 24, 2006, at 5:50 PM, Erik Morton wrote:> In which version of BackgroundRB did you get this result? I threw > together some test code during the summer and had over 100 threads > going at once, which resulted in 100 connections. Each thread then > killed its connection and I didn''t see any deadlock issues. > > Regards, > Erik > On Oct 24, 2006, at 1:33 PM, Ryan Garver wrote: > >> 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 >