[Backgroundrb-devel] Fwd: Accessing cached information during a backgroundrb process

hemant gethemant at gmail.com
Mon Jul 21 07:28:18 EDT 2008

Sorry the thread went off the mailing list, when I clicked reply,
rather than reply all.

---------- Forwarded message ----------
From: Kieran P <kieran776 at gmail.com>
Date: Mon, Jul 21, 2008 at 3:17 PM
Subject: Re: [Backgroundrb-devel] Accessing cached information during
a backgroundrb process
To: hemant <gethemant at gmail.com>

On Mon, Jul 21, 2008 at 5:29 PM, hemant <gethemant at gmail.com> wrote:
> On Mon, Jul 21, 2008 at 10:25 AM, Kieran P <kieran776 at gmail.com> wrote:
> > Hello,
> >
> > We've just updated an application from an older version of backgroundrb to
> > the most recent code available on github.
> >
> > And most of the code is now working as expected, except for one area which
> > is fairly important.
> >
> > We pass the task off to an async function, which proceeds to the next page,
> > on which we have a regular get_status function running. It used to query the
> > worker, get the current information from what was set by register_status and
> > then update the page based on the information it received back.
> >
> > I see that function has been removed in the recent code, and replaced with
> > ask_result. And while this works to get information back at the end of a
> > backgroundrb process, it returns nil if you ask_result while its still
> > running.
> >
> > I've read over the docs, and am fairly certain I've got the syntax right.
> >
> > Is there a function I'm not seeing, that would allow us to be able to get
> > the information we need during a backgroundrb process? And if not, is there
> > a suggested way to get around this?
> >
> > Any help would be greatly appreciated.
> Previously all the cached results were being stored in master process
> and hence even when worker is processing certain requests, you were
> able to fetch the results back. Now this had its own trade-off and
> register_status was never thread safe and hence cached results are by
> default now worker local data and when you invoke ask_result, it gets
> queried from worker (which may not be able to serve the data, because
> its processing some task).
> One very simple and effective workaround is to replace that cache with
> memcache ( actually any production app should use memcache rather than
> default cache that comes bundled). Its quite easy, just update your
> backgroundrb.yml with:
> :backgroundrb:
>  :ip: #ip on which backgroundrb server is running
>  :port: 11006 #port on which backgroundrb server is running
>  :result_storage: memcache # store results in a mecache cluster
> :memcache: "" #=> location of mecache clusters seperated by comma

Thank you hemant. Your solution worked perfectly, without any other
changes (with the exception of an IP change).

backgroundrb is now upgraded and working much smoother than before. Great work.


Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.


More information about the Backgroundrb-devel mailing list