[Backgroundrb-devel] Could a BackgrounDrb worker do this?
ezmobius at gmail.com
Thu Sep 14 13:00:35 EDT 2006
On Sep 13, 2006, at 7:38 AM, Bill Walton wrote:
> Hi Ezra,
> Ezra Zygmuntowicz wrote:
>>> Continuing our conversation from the Rails list.
>> Welcome ;)
>>> Does any of the way I'm thinking about this tell you I'm heading
>>> off 'into the weeds'?
>> Yes you have a few incorrect notions,
> I was afraid of that ;-)
>> let's see if I can clear things up for you a bit.
> I really appreciate it. I should warn you though. Sometimes even
> *I* am surprised by my density ;-)
>> Your backgroundrb worker are not rails controllers at all and they
>> do not directly respond to ajax calls. In your rails app you have
>> access to the MiddleMan object that you can use to start workers
>> in the drb server and ping them for results later during the ajax
> If I can ping the worker from the controller and they can respond
> and my controller can receive and process their response, and
> they're sitting out there running and waiting to respond, I'm not
> getting why they couldn't *initiate* a 'conversation'. Is this a
> 'we don't have a tool built to do that' situation? Or is it 'the
> Rails architecture doesn't allow for that kind of interprocess
> communication' situation?
I'm just not sure what you are trying to accomplish with this. I
think you are making it way more difficult ;) The way backgroundrb
works is mainly a one way thing. You kick off the workers from your
controller and then you can ping the worker later from your
controller to get status or results from it. If you really feel you
need to call back to your controller from the bgdrb server, you could
use net/http in ruby's standard library top make a http request back
to the rails app.
The problem with trying to talk back to rails from the drb server is
that rails is not persistent. Each request instantiates a new
controller object. So if you try to callback to rails from bdrb, you
aren't garanteed to get the same controller object to work with. So
bdrb works by letting rails control it. You kick off your worker
classes with a command in your controller and then you store a job
key in your sessions. Then on later requests in rails you can use
this job key to grab a handle on your worker object and call methods
on it for results.
>> So IU hope that explains it a bit better.
> I have a much better understanding of how to use BackgrounDRb.
> Thank you. But I'm still confused ;-(
> I think, maybe, my confusion comes from associating (in my mind)
> BackgrounDRb and dRuby (drb) as discussed in "Programming Ruby".
> The DRb class description (p.670) says "Although expressed in terms
> of clients and servers, once the initial connection is established,
> the protocol is effectively symmetrical: either side can invoke
> methods in objects on the other side." Could you shed some light
> on this for me?
Yes BackgrounDRb uses drb to do its work. But the way it is designed
is for use with the way rails works. Its a persistent daemon that
runs your jobs. Your rails controllers and models are all
instantiated on each request so they don't persist and thats why you
need a session.
So yes its true that the way drb works is that both ends effectively
become servers and clients. But because rails is a web app, and the
way request/response and object instantiation in rails works, you
can't really call back to rails from backgroundrb. Because the place
you would be trying to call back to won't exist after its request is
More information about the Backgroundrb-devel