[Backgroundrb-devel] Could a BackgrounDrb worker do this?

Ezra Zygmuntowicz ezmobius at gmail.com
Tue Sep 12 14:56:49 EDT 2006

Hi Bill~

On Sep 12, 2006, at 7:45 AM, Bill Walton wrote:

> Hi Ezra,
> Continuing our conversation from the Rails list.

Welcome ;)
> Ezra Zygmuntowicz wrote:
> <snip some very encouraging stuff>
> I'm not sure I'm understanding you here.  Are you saying put the  
> 'cleanup'
> action that deletes the user-entered records and files in the  
> worker?  If
> so, doesn't that go against the DRY principle?  Or are you saying  
> to move it
> from where it is now (in one of the app's controllers) into a worker?
> I'm definitely confused by your statement that "backgroundrb  
> doesn't use
> http so it can't really call a controller method in your app".  I  
> understood
> that workers could respond to Ajax requests.  Did I misunderstand?
> To my limited understanding, if a worker's job is to respond to Ajax
> requests, that means I can think of a backgroundrb worker as just  
> another of
> the app's controllers, albeit a 'special' one because it's running in
> parallel.  Am I 'courting danger' with this simplistic view?
> Now that we've talked about it a little, I guess if it *is* ok to  
> think
> about a worker as one of the app's controllers, then the worker  
> really is
> where I want to put the cleanup code.  I'm also assuming that a worker
> 'knows' what session it's part of.  Is that right?
> 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, let's see if I can clear  
things up for you a bit. 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 requests. But the http requests have to come  
into a normal rails controller, the in a controller action you can  
use MiddleMan to grab a handle on your remote worker object and call  
methods or get vars from it.

	So yes if you are going to be using backgroundrb to do this cleanup  
project I would move the cleanup code into a worker class and remove  
it from your main app. Then in your rails app when you need to call  
the cleanup worker, you use the MiddleMan to do so. And then in the  
cleanup worker you could have a timer that wakes up every X minutes  
and does the cleanup for users who left their session dangling.

	So a worker class might look like this:

class CleanupWorker < BackgrounDRb::Rails

   repeat_every 15.minutes
   first_run Time.now

   def do_work(args)
      # pull the id out of args and do the cleanup
      # or if there is no args then just look for session older then  
X minutes and clean them up.


	Then you would want to autostart this worker so it runs on boot up.  
So you would add this to your backgroundrb.yml config  file:

     job_key: cleanup
     class: cleanup_worker

	And then to access this from your rails app when someone logs out  

# in a controller or model method

def cleanup(user_id)
   MiddleMan.new_worker :class => :cleanup_worker,
                                                :args => user_id,
                                                :ttl => 120

	So now when you call that action, the drb server will create a new  
cleaup worker and pass in the user_id so you can cleanup after that  

> <snip>
>> Ok all that being said, BackgrounDRb can do the same
>> thing for you. [...]  If you decide to go the BackgrounDRb
>> route then please join the mailing list for it and I'll do my
>> best to help you along.
> Well.... here I am! ;-)  And thank you.  You may yet convince me  
> that the
> script/cron route is the way to go.  But first, I need to better  
> understand
> what you're telling me.  In the interest of full disclosure, until  
> finding
> RoR around the first of this year, I've not done any serious  
> development in
> a dozen years.  I've been managing it, but not doing it.  A lot has  
> changed
> and I'm finding there are lots of details I need to learn.
> Best regards,
> Bill

	So IU hope that explains it a bit better. You could go either way  
with this. BackgrounDRb will certainly work for what you need to do.  
But since this is more like a fire and forget type of job, it is less  
moving parts to just use a cron job and a script/runner  script that  
fires the cleanup code. Its up to you which direction to take. I'll  
try to help as much as I can.


More information about the Backgroundrb-devel mailing list