I'm not sure what narrow is by the period is 30 seconds. I'm seeing
weirder behavior now. The task completes successfully but it quits being
executed at a random time. The only way for me to fix it is to restart the
scheduler process. I enabled the debug logging and here are the last two
runs
you could attach the log to the message, so the thread doesn't get long:P
I see 2 rounds only COMPLETED, then a huge gap
2012-12-16 21:39:30,330 - web2py.scheduler - INFO - task completed
(COMPLETED)
2012-12-16 23:12:23,296 - web2py.scheduler - DEBUG - new scheduler_run
record
Sorry about that. I just tried to attach the log and it keeps giving me an
error. The scheduler_task record is marked QUEUED and the last
scheduler_run record is marked COMPLETED. The task just isn't being run for
some reason.
On Monday, December 17, 2012 12:29:34 PM UTC-8, Niphlod wrote:
I have now tried with two different browsers to attach the log with no
success. I keep getting error (340) occurred while communicating with the
server. Do you want me to just email you the log?
On Monday, December 17, 2012 12:45:45 PM UTC-8, Mike D wrote:
Sorry about that. I just tried to
no probl, the email is kinda obvious, at gmail.com
On Monday, December 17, 2012 9:54:38 PM UTC+1, Mike D wrote:
I have now tried with two different browsers to attach the log with no
success. I keep getting error (340) occurred while communicating with the
server. Do you want me to just
are you using sqlite ? It's possible that the timeout is reached because
database is locked and the scheduler_run record (that you confirm is
missing) can't be inserted. Also, just to be sure, did you try raising the
timeout?
If I cannot fix it I will have to find a different solution for
I am using SQLite. The TIMEOUT record in the scheduler_run table eventually
shows up. I can't be sure when since it normally happens over night. I
don't know how to raise a timeout but if you tell me I can try that. That
would help narrow down the issue because if the DB is locked I would not
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
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
unless your tasks have a very narrow period they shouldn't go on timeout on
SQLite (remember to commit if acting on the tables within a task).
W2P_TVSeries uses 500-600 tasks with a watcher task coordinating those
and it doesn't block.
Upgrading to Mysql or PostgreSQL will fix the issue if the
10 matches
Mail list logo
