Backgroundrb devel - Feb 2008 - Suspended start of task not suspended

Hi

I thought this should suspend the task by 1 minute, but it starts  
immediately:

MiddleMan.ask_work( :worker => :bar_worker, :worker_method  
=> :test_method, :trigger_args => { :start => (Time.now + 1.minute)})

Is the start argument not allowed in the new backgroundrb (mine is at  
rev HEAD (=314))? What can I do about this?

I really need to suspend starting the task as I want the client to  
start the trigger but the task itself should wait till about midnight.

Thanks

On Feb 2, 2008 9:31 PM, Ivo Dancet <caifara.subscribe at gmail.com>
wrote:
> Hi
>
> I thought this should suspend the task by 1 minute, but it starts
> immediately:
>
> MiddleMan.ask_work( :worker => :bar_worker, :worker_method
> => :test_method, :trigger_args => { :start => (Time.now +
1.minute)})
>
I do not think passing trigger_args like that is supported at all. No,
it won''t work like that.
> Is the start argument not allowed in the new backgroundrb (mine is at
> rev HEAD (=314))? What can I do about this?

Yes it should be pretty simple to have an implementation like this:

# don''t execute the task now, but delay it by half an hour
def test_method(args = nil)
  add_timer(30*60) { run_actual_method(args) }
end

def run_actual_method args
  # execute the delayed task
end

I know, its not probably very elegant, but should suffice.
Let us know, if we missed something in above simplistic implementation.
-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org

On Feb 2, 2008 10:27 PM, hemant <gethemant at gmail.com>
wrote:
>
> Yes it should be pretty simple to have an implementation like this:
>
> # don''t execute the task now, but delay it by half an hour
> def test_method(args = nil)
>   add_timer(30*60) { run_actual_method(args) }
> end
>
> def run_actual_method args
>   # execute the delayed task
> end
>
Also, if you need to set that time dynamically from rails, then you
can pass time as an argument to test_method,

MiddleMan.ask_work(:worker => :foo_worker,:worker_method =>
:test_method, :data => { :firetime => 60,:args => "bar"})

and in test_method

def test_method args
  add_timer(args[:firetime]) { fire_method(args[:args]) }
end

Op 2-feb-08, om 17:57 heeft hemant het volgende geschreven:
> On Feb 2, 2008 9:31 PM, Ivo Dancet <caifara.subscribe at gmail.com>  
> wrote:
>> Hi
>>
>> I thought this should suspend the task by 1 minute, but it starts
>> immediately:
>>
>> MiddleMan.ask_work( :worker => :bar_worker, :worker_method
>> => :test_method, :trigger_args => { :start => (Time.now +
1.minute)})
>>
>
> I do not think passing trigger_args like that is supported at all. No,
> it won''t work like that.

ok, hmmm, I''m going to have to look at it a bit closer. I thought it  
was going to work because it used to work in the previous  
backgroundrb. I relied heavily on that feature. Going to have to  
rewrite some code...

Thanks for the quick answer!

Hello,

I have a few tasks that run every few minutes.  They definitely need their
own worker.

However, other tasks run once per day or even once per week.  Right now I am
creating a new worker for each of these tasks, but I wonder if that''s
unnecessary for tasks that I know will never execute at the same time.  They
don''t need to run concurrently.

Basically, I am wondering if I should combine a bunch of these periodic,
non-overlapping tasks into one worker called
"general_maintenance_worker" or
something like that.  For each task, I could create a different method and
schedule them as needed in backgroundrb.yml.

That should work, but is it "right"?  What''s the "best
practice" is in this
situation?

Thanks,

Scott

On Feb 5, 2008 12:37 AM, Scott Ward <scott at shefield.com>
wrote:
> Hello,
>
> I have a few tasks that run every few minutes.  They definitely need their
> own worker.
>
> However, other tasks run once per day or even once per week.  Right now I
am
> creating a new worker for each of these tasks, but I wonder if
that''s
> unnecessary for tasks that I know will never execute at the same time. 
They
> don''t need to run concurrently.
>
> Basically, I am wondering if I should combine a bunch of these periodic,
> non-overlapping tasks into one worker called
"general_maintenance_worker" or
> something like that.  For each task, I could create a different method and
> schedule them as needed in backgroundrb.yml.
>
> That should work, but is it "right"?  What''s the
"best practice" is in this
> situation?

Yup, if your tasks are non-overlapping then you can put them in the
same worker and through backgroundrb.yml
you can configure them to run at different intervals.


-- 
Let them talk of their oriental summer climes of everlasting
conservatories; give me the privilege of making my own summer with my
own coals.

http://gnufied.org

On Feb 4, 2008 2:07 PM, Scott Ward <scott at shefield.com>
wrote:
>
> Basically, I am wondering if I should combine a bunch of these periodic,
> non-overlapping tasks into one worker called
"general_maintenance_worker" or
> something like that.  For each task, I could create a different method and
> schedule them as needed in backgroundrb.yml.
>
> That should work, but is it "right"?  What''s the
"best practice" is in this
> situation?
I am planning on doing the exact same thing for my periodic tasks. I
think it makes sense so let''s make it into a BackgrounDRb best
practice :)

The thing to keep in mind is each worker gets a Ruby process, which
can consume 20-40 MB of memory. So if you can combine workers it will
definitely save resources. There really isn''t a good reason I can
think of to have a bunch of workers sitting around just to be run one
or twice a day. So might as well put them all into one worker.
Especially if you can schedule tasks so they never overlap.

The way to keep this from getting too messy (as in a worker with tons
of unrelated code) is to extract the real work into separate ruby
modules which are required in the worker and then called from the
worker methods. Well that is how I have written things :)

Ryan