[Backgroundrb-devel] Upgrading to 2.0

hemant gethemant at gmail.com
Sat Jan 19 22:44:08 EST 2008


On Jan 20, 2008 7:50 AM, Dale Cook <dale at dalecook.us> wrote:
> We're currently using a really old version of BackgrounDRb in a small
> production environment and we're thinking about upgrading to 2.0, primarily
> because we want to push it a little harder and have it manage a few more
> things. Problem is, we're a little confused on some changes that have been
> made to the new version. Perhaps these are stupid questions, or perhaps they
> have been answered elsewhere, but we can't find them in the mailing list
> archive, and the current documentation doesn't seem to address them, so here
> goes:
> 1. Auto-generated job keys.
> In our current version we can do something like
> @job_key = MiddleMan.new_worker(:class => :test_worker, :args => {"some args
> go here"})
> which will return back a automatically generated random job key that we can
> then use to access the worker at a later stage. 2.0 doesn't seem to do this,
> but instead requires us to generate a job key for it - is this right or are
> we just missing something?

Yes thats right, you will have to specify your job_key while calling the worker.
Even in older versions, you had the option to supply the job_key.

> 2. Accessing a particular working
> In our version we can access a particular worker by doing something like:
> my_worker = MiddleMan.get_worker(@job_key)
> which, of course, returns our worker. There doesn't seem to be a similar
> function for 2.0. We've seen the example for getting all the workers, but
> not an example for getting one particular worker. Is this possible?

There is a major difference that in older version you had access to
worker environment through DRb.
For stability sake, there are no threads and hence you don't have
direct access to worker environment.

If you want to execute a task, you have to use:

MiddleMan.ask_work(:worker => :foo_worker,:job_key => @job_key)

> 3. Accessing worker attributes
> We have some workers that are defined something like this:
> class TestWorker < BackgrounDRb::Rails
>   attr_reader :progress
>   attr_reader :total
>   attr_reader :status
>   def do_work(args = nil)
>     @status = "started"
>     @total = some_object.length
>     #blah blah blah...
>     @status = "working"
>     @progress += 1
>     #blah blah blah...
>     @status = "complete"
>   end
> end
> For long running tasks we'd grab the worker object similar to the example
> given in 2 above and then query it's parameters like so
> puts my_worker.status
> puts my_worker.length
> while(my_worker.progress < 100)
> {
>   puts my_worker.progress
> }
> Now, we realise that you can use something like MiddleMan.ask_status(:worker
> => :foo_worker) but it seems that it's possible to only have one attribute
> per worker. Is it possible to have multiple attributes per worker and if so
> how do we access them?
> We've actually spent some time trying out a few of these things but we've
> had very little success. I suspect that the new 2.0 system is so different
> from the version that we're using that we're just having a difficult time
> getting our heads around it. Any help here would be greatly appreciated.

Again remember you don't have direct access to worker environment
through MiddleMan. Its probably good and bad. Good because it reduces
complexity and bad because it sacrifices on flexibility. However, you
can easily compile your attributes in a hash and access it from rails.
For example:

class HelloWorker < BackgrounDRb::MetaWorker
  set_worker_name :hello_worker
  def create(args = nil)
    @worker_attributes = {:length => 0, :percentage => 0}

   def start_work
     loop do
        # do some processing
     @worker_attributes[:length] = 100
     @worker_attributes[:percentage] = 100

Issue of not able to access worker attributes, is it a blocker for you?

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