Hi,
The worker looks like that:
class NotificationWorker < BackgrounDRb::MetaWorker
set_worker_name :notification_worker
reload_on_schedule true
def create(args = nil)
# time argument is in seconds
end
def do_it
logger.info('NotificationWorker do it start')
begin
Idea.notify_users
rescue Exception => e
logger.error("Idea.notify_users Exception: #{e.to_s}
#{e.backtrace.join('\\n')}")
end
logger.info('NotificationWorker do it end')
end
end
Recover - we removed the scheduling and trigger only daily right now.
Not sure if it would work today (after the day that has only 23
hours). but as it is a production system we did not try it.
Regards
Till
MindMeister - MeisterLabs GmbH
Till Vollmer
Managing Director
Tel: +49 (0)89 1213 5359
Mob: + 49 (0)160 718 7403
Fax: +49 (0)89 1892 1347
Yahoo ID: till_vollmer
Skype: till_vollmer
www.mindmeister.com
Am 30.03.2009 um 14:31 schrieb hemant:
On Mon, Mar 30, 2009 at 3:29 PM, Till Vollmer <[email protected]>
wrote:
Hi,
we have encountered a severe bug in backgroundrb last weekend.
On Sunday at 20:00 (EST) backgroundrb launched infinite workers of
notification_worker and our server was killed because of memory
consumption.
:backgroundrb:
:port: 11006
:ip: 0.0.0.0
:persistent_disabled: true # turn this off if your application
doesn't use
backgroundrb's persistent/enqueued tasks system
:persistent_delay: 10 # the time (seconds) between each time
backgroundrb
checks the database for enqueued tasks
:schedules:
:notification_worker:
:do_it:
:trigger_args: 0 30 */4 * * * *
We think that it might be related to daylight saving time.
Any hints appreciated.
Were you using reload_on_schedule ?? But yes, the bug do seem like
triggered by DST, I will be pushing out an update that will contain
the fix.
BTW, were you able to recover the worker?
_______________________________________________
Backgroundrb-devel mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/backgroundrb-devel
