[Backgroundrb-devel] periodic scheduling

Jack Nutting jnutting at gmail.com
Thu Jan 17 15:26:49 EST 2008

On Jan 17, 2008 6:41 PM, hemant <gethemant at gmail.com> wrote:
> Yuck. Never use sleep() in new backgroundrb workers. :)

Yeah, I wasn't really 100% happy with that solution either...  I will
change my ways!

> I am still unclear about whats your purpose of using bdrb? If you just
> want to use it to schedule tasks, then you can specify your schedule
> in config file, using either Cron on UNIX syntax and it will work.

Good question!  At an earlier stage in my application's design, there
was a place for more standard backgroundrb usage, with some processing
that was triggered by user actions.  I liked the way it worked, and
was enough of a rails noob that I frankly didn't know any other way to
do background tasks that accessed activerecord, my model classes, etc,
so I started using backgroundrb for perpetually-running processes as
well;  eventually these also incorporated the functions that were
previously performed by user actions as well, and there I am today.
Maybe I should just stop using backgroundrb for now, until I have a
use that better matches its intended purpose.

> If
> you are scheduling at in interval of 10 seconds and your actual tasks
> takes longer than that, then also there is nothing to worry and bdrb
> will schedule tasks as they are ready to run and worker is free. So
> your tasks won't be piling up.

Ah, OK.  I picked up a different meaning from this text in the README,
the Cron Scheduling section:

  The method specified in the configuration
  file would be called periodically. You should accommodate
  for the fact that the time gap between periodic
  invocation of a method should be more than the time
  that is actually required to execute the method.
  If a method takes longer time than the time window
  specified, your method invocations will lag

Doesn't that seem to be saying that requests will be piling up?

> ask_work() is for doing one shot task execution. It can be only used
> in a already runner worker. If you started a worker with a job_key
> using new_worker() method, then you will have to use that job_key
> along with worker name in ask_work() or ask_status() invocation.

OK, I didn't realize you could use job_key with ask_work().  Now it
makes sense to me.

> > Next, is there any way from inside a worker to see what its job_key
> > is?
> Sad truth of life is that, you can't. Not from inside of a worker. But
> since inside any worker you have full rails environment and hence
> MiddleMan proxy object, you can query job_key using:
> MiddleMan.worker_info(:worker => worker_name.to_sym)

It also occurred to me that I could pass the job_key in with the data
parameter when I create the worker.

> new_worker() creates a full forked process. ask_work(), send_request()
> can only operate on workers which are already running.

Thanks for the clarification.

> And lastly, sorry for documentation, if you found it a bit out of
> touch. *vows to improve it*

No problem, I appreciate that the documentation is there at all, and
most of all that you've picked up the backgroundrb ball and run with
it!  Keep up the good work!

// jack
// http://www.nuthole.com

More information about the Backgroundrb-devel mailing list