[Backgroundrb-devel] periodic scheduling
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.
> 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!
More information about the Backgroundrb-devel