Thanks for the reply.
I see, since results outlive the worker, so I can call self.delete
right at the end of do_work method without worrying the results would
be gone, right? Wouldn''t this be always preferrable (the worker
delete itself when done)? All examples I see suggest that the Rails
application has to delete the worker.
Just curious how long does the persistent Result worker keeps
worker.results data around? or is there a config to set this? since
this might increase the memory usage when you get a lot of worker
request, right?
hemant, sorry for the duplicate email, I didn''t hit reply all at first
:)
- reynard
On Nov 7, 2007 1:36 PM, hemant <gethemant at gmail.com>
wrote:> On 11/7/07, Reynard <reynard.list at gmail.com> wrote:
> > Hi,
> >
> > I''m using backgroundrb 0.2.1 and having problem with worker
processes
> > staying around when the rails application does not explicitly delete
> > them.
> >
> > Is there a way to automatically delete the worker processes when it
> > has completed the job?
> You can use worker.delete method or from inside of a worker
> self.delete to terminate the worker.
>
> > Also does killing the process manually (using kill command) harm the
> > backgroundrb server? I have some occasions where the backgroundrb
> > server just hangs, or throws strange errors (which suggests that the
> > worker.results data was corrupted)
> >
>
> There are some unsolved issues with result data corruption and stuff.
> A new release of backgroundrb is around the corner ( this weekend, i
> hope to get it out of pre-release, and implement crontab schedulers,
> unix schedulers and stuff).
>
> --
> 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
>