I have only this one task. I am certainly going to change the retry_failed and hopefully that will be a sufficient solution. I actually tried your other solution a while ago and that "monitoring" task actually ended up in a TIMEOUT state as well. Sad face. Any idea on that one?
Do you think that switching database providers would help or is it not worth the effort? Thanks again for your help. On Thursday, December 13, 2012 11:57:01 AM UTC-8, Niphlod wrote: > > All my statements were made under the assumption that the scheduler_run > table showed absolutely no trace of the TIMOUTted task. > > In any case, running the scheduler on SQLite is "safe" only for 1 or 2 > workers and not with a zillion of tasks. Concurrency was never a friend of > SQLite. > > BTW, at this point enable the debug logging of the scheduler: can be quite > a long log keep it for a day or two, but if you can't reproduce the error > at will, it's the only hope to see what is really going on. > > PS: confirmed: TIMEOUTted tasks do end up requeued with retry_failed != 0 > > PS2: don't underestimate the flexibility of the scheduler. Even if > retry_failed was not available, you can always use another task that checks > on the scheduler_task table for the "original" task and requeue it :P > > > --
