I have a worker which wants to delete itself after it finishes its work- how can it do that? Best Regards, Danny Burkes
Danny, put "exit" on the last line def create #... do stuff exit end (can be called anywhere in the worker, in other methods etc). On 1/10/08, Danny Burkes <dburkes at infoteria.com> wrote:> > I have a worker which wants to delete itself after it finishes its > work- how can it do that? > > Best Regards, > > Danny Burkes > _______________________________________________ > 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/20080110/808d0d3a/attachment.html
> put "exit" on the last line > > def create > #... do stuff > exit > end > > (can be called anywhere in the worker, in other methods etc). >That doesn''t seem to work- I still see the ruby process in ps. This is a dynamically-created worker, and I want to exit the entire process once it is finished. Any other ideas? Thanks, Danny
exit is definitely the command (its the ruby kernel method for ending the
process). though i''ve never running into it not working. are you sure
its
getting as far as the exit command (not hanging up on a loop etc)? try
logger.info(''before exit'') and ''after exit''
to see if that shows up in the
backgroundrb.log.
i''m assuming you''ve read the docs and understand the
"set_no_auto_load
true") method etc, so ruling out the possibility of it just been a
different
copy of the worker..
On 1/10/08, Danny Burkes <dburkes at infoteria.com>
wrote:>
> > put "exit" on the last line
> >
> > def create
> > #... do stuff
> > exit
> > end
> >
> > (can be called anywhere in the worker, in other methods etc).
> >
>
> That doesn''t seem to work- I still see the ruby process in ps.
This
> is a dynamically-created worker, and I want to exit the entire process
> once it is finished. Any other ideas?
>
> Thanks,
>
> Danny
> _______________________________________________
> 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/20080110/127e1264/attachment-0001.html
> exit is definitely the command (its the ruby kernel method for > ending the process). though i''ve never running into it not working. > are you sure its getting as far as the exit command (not hanging up > on a loop etc)? try logger.info(''before exit'') and ''after exit'' to > see if that shows up in the backgroundrb.log. >Ah, thanks- a closer examination of the logfile revealed that you are right. Thanks for your help- D
By co-incidence I have the same use case - the (dynamically created) worker process is exiting just fine when it hits the exit at the end of the create method. However, subsequent calls to MiddleMan.query_all_workers still lists the worker and its last known status. I have a web UI for monitoring worker activity so this is a little misleading for our admins. Is there any way to get the master to realize the worker is gone? I am also seeing "Some read error" messages in the backroundrb console and judging from a related discussion at http://rubyforge.org/pipermail/backgroundrb-devel/2007-December/001146.html the master isn''t cleaning up the socket connection to the worker (and removing the worker from its internal lists). (I''m running from the 1.0 release tag btw). John. On 10 Jan 2008, at 17:17, Zachary Powell wrote:> exit is definitely the command (its the ruby kernel method for > ending the process). though i''ve never running into it not working. > are you sure its getting as far as the exit command (not hanging up > on a loop etc)? try logger.info(''before exit'') and ''after exit'' to > see if that shows up in the backgroundrb.log. > > i''m assuming you''ve read the docs and understand the > "set_no_auto_load true") method etc, so ruling out the possibility > of it just been a different copy of the worker.. > > On 1/10/08, Danny Burkes <dburkes at infoteria.com> wrote: > > put "exit" on the last line > > > > def create > > #... do stuff > > exit > > end > > > > (can be called anywhere in the worker, in other methods etc). > > > > That doesn''t seem to work- I still see the ruby process in ps. This > is a dynamically-created worker, and I want to exit the entire process > once it is finished. Any other ideas? > > Thanks, > > Danny > _______________________________________________ > 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-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080110/784595ea/attachment.html
On Jan 11, 2008 1:12 AM, John O''Shea <joshea at nooked.com> wrote:> By co-incidence I have the same use case - the (dynamically created) worker > process is exiting just fine when it hits the exit at the end of the create > method. However, subsequent calls to MiddleMan.query_all_workers still > lists the worker and its last known status. I have a web UI for monitoring > worker activity so this is a little misleading for our admins.Thats intentional, although name is a misnomer I admit. But if you want to find the workers which are currently running,use MiddleMan.all_worker_info> > Is there any way to get the master to realize the worker is gone? I am also > seeing "Some read error" messages in the backroundrb console and judging > from a related discussion at > http://rubyforge.org/pipermail/backgroundrb-devel/2007-December/001146.html > the master isn''t cleaning up the socket connection to the worker (and > removing the worker from its internal lists). > > (I''m running from the 1.0 release tag btw).Master DOES realize when a worker is gone and please upgrade to trunk or 1.0.1 release. Its rather important and above method(all_worker_info) has been added in 1.0.1 only. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org
hemant,
Thanks for the pointer, works well on HEAD. For the benefit of
others, the all_worker_info method returns an array of hashes (one for
each worker) containing the following keys
:worker (value is name)
:job_key (value is an empty string if no job key assigned)
:status (value seems to be hardcoded to ''running'')
I''m not sure if the hardcoded status is intentional but I''m
working
around with something like
@workers = MiddleMan.all_worker_info
@workers.each { |worker|
worker[:status]= worker[:job_key].empty? ?
MiddleMan.ask_status(:worker => worker[:worker]) :
MiddleMan.ask_status(:worker => worker[:worker], :job_key =>
worker[:job_key])
}
John.
On 10 Jan 2008, at 20:16, hemant wrote:
> On Jan 11, 2008 1:12 AM, John O''Shea <joshea at nooked.com>
wrote:
>> By co-incidence I have the same use case - the (dynamically
>> created) worker
>> process is exiting just fine when it hits the exit at the end of
>> the create
>> method. However, subsequent calls to MiddleMan.query_all_workers
>> still
>> lists the worker and its last known status. I have a web UI for
>> monitoring
>> worker activity so this is a little misleading for our admins.
>
> Thats intentional, although name is a misnomer I admit. But if you
> want to find the workers which are currently running,use
> MiddleMan.all_worker_info
>
>>
>> Is there any way to get the master to realize the worker is gone?
>> I am also
>> seeing "Some read error" messages in the backroundrb console
and
>> judging
>> from a related discussion at
>>
http://rubyforge.org/pipermail/backgroundrb-devel/2007-December/001146.html
>> the master isn''t cleaning up the socket connection to the
worker (and
>> removing the worker from its internal lists).
>>
>> (I''m running from the 1.0 release tag btw).
>
> Master DOES realize when a worker is gone and please upgrade to trunk
> or 1.0.1 release. Its rather important and above
> method(all_worker_info) has been added in 1.0.1 only.
>
> --
> Let them talk of their oriental summer climes of everlasting
> conservatories; give me the privilege of making my own summer with my
> own coals.
>
> http://gnufied.org
Hi John, On Jan 11, 2008 4:52 AM, John O''Shea <joshea at nooked.com> wrote:> hemant, > Thanks for the pointer, works well on HEAD. For the benefit of > others, the all_worker_info method returns an array of hashes (one for > each worker) containing the following keys > :worker (value is name) > :job_key (value is an empty string if no job key assigned) > :status (value seems to be hardcoded to ''running'')Hmm, the API has become a bit confusing. But I will try to clear it up and I will be putting this up in READE too. As you probably know, BackgrounDRb offers ability to store result hashes from workers, so as even when a worker is died and no longer running, you can query the results computed by it. This is immensely useful. MiddleMan.ask_status() method returns the result set for this particular worker. Result set will be available even after a worker is no longer running. Similarly, MiddleMan.query_all_workers is for getting all available result sets in one go. BackgrounDRb 1.0.1 offers ability to detect running workers and stuff and worker_info methods are solely for that purpose. For example: MiddleMan.worker_info(:worker => :foo_worker) Will return :status = :running if ''foo_worker'' is running and will return :status = :stopped if not running. I do not think apart from these two values any other state can be possible for a worker and hence its hardcoded. Similarly MiddleMan.all_worker_info returns information about all currently running workers. -- Let them talk of their oriental summer climes of everlasting conservatories; give me the privilege of making my own summer with my own coals. http://gnufied.org