Thanks Niphlod for your tips. The idea of having a separate db for the
scheduler crossed my mind when I noticed the "db" parameter for the
Scheduler constructor; however, in my case, I have **multiple instances of
web2py** (instead of a single instance with multiple apps), like this:
/var/www/web2py1/web2py.py
/var/www/web2py1/applications/myapp
/var/www/web2py1/applications/myapp/models/scheduler.py
/var/www/web2py2/web2py.py
/var/www/web2py2/applications/myapp
/var/www/web2py2/applications/myapp/models/scheduler.py
/var/www/web2py3/web2py.py
/var/www/web2py3/applications/myapp
/var/www/web2py3/applications/myapp/models/scheduler.py
so I guess it's not possible to run only one scheduler (using the web2py.py
of the first instance) and getting it execute the tasks queued by the other
web2py instances, in spite of they are using the same db for the
scheduling. Please correct me if I'm wrong.
If I'm correct about last thing, and, considering that I don't want to
depend on OS cron, then question is: would it be correct to queue the task
in the follow way?
scheduler.queue_task(
send_newsletter, # the function that sends the newsletter
start_time=first_execution, # first_execution would be, for
example, tomorrow at 8am
period=86400, # one day, expressed in seconds
repeats = 0 # unlimited repeats
)
That is, the task is queued one first time, with a period of one day and
unlimited repeats. If this is the case, would it make sense to set the
scheduler's heartbeat to, let's say, 10 minutes or more?
2014-12-24 15:03 GMT-03:00 Niphlod <niph...@gmail.com>:
> 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 a topic in the
> Google Groups "web2py-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/web2py/LZYGjEX3bXg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
