STOPPED tasks gets requeued as soon as there is an ACTIVE worker around. The "philosophy" behind is that if a worker has been stopped (abruptly) your task never finished, so it gets "another shot" with the next worker. The scheduler_run table will grow as long as you need results. As documented, if your function doesn't return anything, the corresponding scheduler_run record is deleted. The scheduler_task table will grow as long as you queue tasks..... you can always cleanup it without issues deleting all tasks marked COMPLETED, if you don't need to store those undefinitely.
On Wednesday, July 18, 2012 8:28:03 AM UTC+2, Andrew wrote: > > When I Kill a Task, I end up with a Queued Task and a Stopped > Scheduler_run. When I restart the worker, should I expect the queued task > to then get assigned ? > > I tried killing the worker in the assigned state, and I noticed it is > assigned to a specific worker. If that worker is killed and another > restarted, the task is left assigned to a worker that doesn't exist ? > What happens next. Should I just clear out the task and create a new task. > > What happens to scheduler_task and scheduler_run over time. Will there > only be one row per task/function in scheduler_run, will scheduler_run > slowly fill up for each run - so that I would have to occasionally have to > purge. > > I'll do some more testing in the next few days but I really like the way > you've put this together. > > On Wednesday, July 18, 2012 5:24:16 PM UTC+12, Andrew wrote: >> >> Great Job with packaging up the app and the documentation/instructions. >> Very impressive. >> I'll now start testing / familiarising myself with the scheduler .... >>> >>> >>>>>> >> --
