And the reason i think the behavior's inconsistent is because when you complete an attempt on a repeating task it is immediately requeued to fulfill its repeat obligations, and the last go-around is forgotton- so i think failures should be handled the same way.
On Sat, Aug 18, 2012 at 4:32 PM, Yarin Kessler <ykess...@gmail.com> wrote: > 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. >>>> >>>> >>>> >>>> -- >> >> >> >> > > --
