I've noticed that repeating tasks that fail during a certain period are no longer repeated and the task is turned to FAILED. I think this is inconsistent behavior. The better approach would be:
- Allow a periodic task to fail during a given period - Reset the task to QUEUED, just like when a periodic task completes - Have the scheduler_run table record the failure In other words, retry_failed should apply to the current repeated attempt, not to the totality of the task. Another smaller issue- in the scheduler_task table definition, can we place the last_run_time field betwen the start_time and next_run_time fields. This way they are grouped clearly in the appadmin screens. Thanks-- On Thursday, July 12, 2012 4:36:38 PM UTC-4, Niphlod wrote: > > Hello everybody, in the last month several changes were commited to the > scheduler, in order to improve it. > Table schemas were changed, to add some features that were missed by some > users. > On the verge of releasing web2py v.2.0.0, and seeing that the scheduler > potential is often missed by regular web2py users, I created a test app > with two main objectives: documenting the new scheduler and test the > features. > > App is available on github (https://github.com/niphlod/w2p_scheduler_tests). > All you need is download the trunk version of web2py, download the app and > play with it. > > Current features: > - one-time-only tasks > - recurring tasks > - possibility to schedule functions at a given time > - possibility to schedule recurring tasks with a stop_time > - can operate distributed among machines, given a database reachable for > all workers > - group_names to "divide" tasks among different workers > - group_names can also influence the "percentage" of assigned tasks to > similar workers > - simple integration using modules for "embedded" tasks (i.e. you can use > functions defined in modules directly in your app or have them processed in > background) > - configurable heartbeat to reduce latency: with sane defaults and not > toooo many tasks queued normally a queued task doesn't exceed 5 seconds > execution times > - option to start it, process all available tasks and then die > automatically > - integrated tracebacks > - monitorable as state is saved on the db > - integrated app environment if started as web2py.py -K > - stop processes immediately (set them to "KILL") > - stop processes gracefully (set them to "TERMINATE") > - disable processes (set them to "DISABLED") > - functions that doesn't return results do not generate a scheduler_run > entry > - added a discard_results parameter that doesn't store results "no matter > what" > - added a uuid record to tasks to simplify checkings of "unique" tasks > - task_name is not required anymore > - you can skip passing the function to the scheduler istantiation: > functions can be dinamically retrieved in the app's environment > > So, your mission is: > - test the scheduler with the app and familiarize with it > Secondary mission is: > - report any bug you find here or on github ( > https://github.com/niphlod/w2p_scheduler_tests/issues) > - propose new examples to be embedded in the app, or correct the current > docs (English is not my mother tongue) > > Once approved, docs will be probably embedded in the book ( > http://web2py.com/book) > > Feel free to propose features you'd like to see in the scheduler, I have > some time to spend implementing it. > > > > --