[Backgroundrb-devel] best approach to managing workers and getting status
swertyui at gmail.com
Wed Jul 16 03:54:47 EDT 2008
Would bdrb's queueing mechanism allow for prioritizing of tasks?
I have a few long-running low priority tasks that I'd want to run on the
condition that no high priority tasks are in the queue.
Jack's solution makes sense to my newbie brain, each time my
queue_processing_worker accesses the table, it can sort unprocessed tasks by
priority and begin from there. But I'd rather stick to bdrb convention if
it's inbuilt already.
On Wed, Jun 25, 2008 at 7:20 AM, hemant <gethemant at gmail.com> wrote:
> On Wed, Jun 25, 2008 at 4:30 PM, Frank Schwach <f.schwach at uea.ac.uk>
> > Hemant,
> > These latest additions to backgroundrb look pretty cool. Unfortunately,
> > I don't think I will be able to use it this way because in my setup I
> > can't run anything on the cluster nodes directly. I have to submit jobs
> > to a queuing system on the cluster's master node, which is why I think a
> > simple daemon running on the master node that polls the (remote) db for
> > pending jobs and then submits these to the queue would probably be
> > better for my case - but I'm far from being an expert on distributed
> > systems so any suggestions are very welcome!
> Hmm, so use db queuing mechanism inbuilt in bdrb. bdrb still stays
> lightweight because most of these changes aren't affecting core and
> have really went into client side of code.
> Above snippet does exactly that. But anyways, i think you feel its too
> complicated for your setup? I can't help that feeling. Its
> complicated, if its complicated to setup and use, but its not. Those
> features totally stay out of your way, if you don't need them.
> Backgroundrb-devel mailing list
> Backgroundrb-devel at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Backgroundrb-devel