a) Some people never consider this as a possibility, but if you have 3 apps, e.g. app1, app2 and app3, you can run one scheduler for all applications. The default "mode" is built to process by default tasks coming from the same app that queues them, but the switch is still there: application_name... The only thing to make sure would be to queue tasks with the explicit application_name='.....', e.g. mysched.queue_task(thefunction, ...., application_name='app1') . In that way you can even queue a task defined in app2 from app1. If instead your defined tasks in app1 are queued only within app1, the explicit application_name is not needed. Of course, the database used by the scheduler would have to be the same, and once it's the same, no matter what appname you pass to the -K parameter...it will process any task queued in there (i.e. from ALL apps) without issues.
b) If you don't care about leaving the possibility up to the users to receive those notification at ultra-fine-grained times, e.g. 2:37AM, but only e.g. at 00:00, 00:30, 01:00 (every half hour) and so on, you can avoid having the scheduler always active.... you can istantiate it with mysched = Scheduler(dbsched, max_empty_runs=10) and start the scheduler with web2py.py -K app1 every half hour. A worker will then fired up, will process all queued tasks and then it be terminated automatically after 10 "empty loops", i.e. 10 rounds where no new tasks are found. I use a lot this "pattern" for e.g., a high number of tasks that needs to be processed before arriving at the office, at 6:00am. The usecase is pretty much "leave all the raw data coming in during the day, aggregate and do some report on it at fixed intervals"..... in my case, I know that during the day tasks gets queued, but I only need to run them (aggregation and reporting) by 7:00am on the next morning, so I just start the scheduler at 6:00am, let it process all the backlog and then die gracefully when there's no work to do. c) to have the task execute on the exact same time every day, you're encouraged to pass also the prevent_drift parameter set to True. This is explained in the book... quote: *Default behavior: The time period is not calculated between the END of the first round and the START of the next, but from the START time of the first round to the START time of the next cycle). This can cause accumulating 'drift' in the start time of a job. After v 2.8.2, a new parameter prevent_drift was added, defaulting to False. If set to True when queing a task, the start_time parameter will take precedence over the period, preventing drift* -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
