The problem is, #new_worker, syntax has changed as well:
http://backgroundrb.rubyforge.org/rails/
MiddleMan.new_worker(:worker => :foo_worker,:worker_key => "my_secret_job_key")
On Tue, Sep 23, 2008 at 3:59 AM, Jack Nutting <[EMAIL PROTECTED]> wrote:
> So I've got my background workers up and running, but hit trouble as
> soon as one of them tries to talk to another. For example, I've got a
> worker that was created like this:
>
> MiddleMan.new_worker(:worker=>:receiver, :job_key=>:r, :data=>{:job_key=>:r})
>
> Later, I try to get access to this, in order to asynchronously call
> the method "work_wrapper" on it, like this:
>
> MiddleMan.worker(:receiver, :r).async_work_wrapper()
>
> Unfortunately, this gaves me a backtrace in the debug log, with this at the
> top:
>
> Invalid worker with name receiver_r and key r
> /opt/local/lib/ruby/gems/1.8/gems/packet-0.1.7/lib/packet/packet_connection.rb:52:in
> `ask_worker'
>
> (at first I encountered this while running with packet 0.1.13, and
> downgraded to 0.1.7 in case something had changed, but the problem is
> just the same)
>
> There seems to be a mismatch between what I'm passing to new_worker
> and later to worker. I do need to distinguish between multiple
> instances of some of my workers, so I do need the job_key, but I guess
> I'm passing it incorrectly. Any help would be appreciated!
>
> --
> // jack
> // http://www.nuthole.com
> _______________________________________________
> Backgroundrb-devel mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/backgroundrb-devel
>
--
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
_______________________________________________
Backgroundrb-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/backgroundrb-devel
