I think retry_failed and repeats are two distinct concepts and shouldn't be mixed.
For example, a task set to (repeats=0, retry_failed=0, period=3600) should be able to fail at 2:00pm, but will try again at 3:00pm regardless of what happened at 2:00. Likewise, if it was set to (repeats=0, retry_failed=2,period=3600), and failed all three times at 2:00pm, the retry count should be reset on the next go around. I think it's safer to presume that if a task is set up for indefinite repitition, a failure on one repeat should not bring down the whole task- rather the transactional unit that constitutes a failure should be limited to the any given attempt, repeated or not. This was one of the reasons i pressed for renaming repeats_failed to retry_failed- distinct concepts On Sat, Aug 18, 2012 at 2:56 PM, Niphlod <niph...@gmail.com> wrote: > Can you elaborate further on the inconsistent behaviour ? > repeats requeues the task n times (defaults to only completed tasks) and > retry_failed make them requeued if execution fails. You have parameters to > let the task be like a cron one (repeats=0, retry_failed=-1). > You have also all the bits to manage your tasks (and I don't "catch" the > inconsistency). Are you seeking for supporting some kind of "requeue task > only if failed at most 2 times in a 2 minutes timeframe" ? > > > On Saturday, August 18, 2012 7:45:46 PM UTC+2, Yarin wrote: >> >> 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 <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<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. >>> >>> >>> >>> -- > > > > --
