Am Montag, 13. August 2012 22:32:19 UTC+2 schrieb Niphlod: > > Ok, done (the "save output for TIMEOUTted tasks"). >
That's great! If you want I can test it. > Small issue, but quite manageable: when a task "timeouts" the output now > is saved, and you have the traceback to see "where" it stopped. > e.g. queue function1 with a timeout of 5 seconds > > def function1(): > time.sleep(3) > print "first print" > time.sleep(5) > print "second print" > > > > The scheduler_run records will report: > > 1. status = TIMEOUT > 2. output = first print > 3. traceback = > > /web2py/gluon/scheduler.py", line 203, in executor > result = dumps(_function(*args,**vars)) > File "applications/w2p_scheduler_tests/models/scheduler.py", line 21, > in function1 > time.sleep(5) > File "/home/niphlod/Scrivania/web2py_source/web2py/gluon/scheduler.py", > line 446, in <lambda> > signal.signal(signal.SIGTERM, lambda signum, stack_frame: sys.exit(1)) > SystemExit: 1 > > > > Is that ok ? The "small issue" here is that the traceback is "full", > starting from where the process is stopped after 5 seconds (the executor > function), to the "where" it really stopped (line 21, function1, in > models/scheduler.py) that is the useful information. > I wouldn't consider this an issue, actually it's a feature, isn't it? > Should the scheduler report only the output and not the traceback for > TIMEOUTted tasks? > > On Wednesday, August 8, 2012 3:25:13 PM UTC+2, Daniel Haag wrote: >> >> Hi Niphlod, >> >> thanks for the great work with the scheduler, I'm using it in a project >> where it handles lots of big data imports into a database and the migration >> to your version was without any problems. >> >> On thing catched my eye in the old version and it still seems to be a >> "problem/missing feature" in the new one. When a long running process gets >> executed and produces output (print etc.) this output is written to the >> database only after the task was run (and finished). It would be really >> great if the output gets written into the task table while the task runs as >> this would be a possible feedback mechanism (and we would not need another >> table etc. just for that) just thinking of a progress meter for example. >> >> What I really miss though is the output of the task when it produces a >> timeout - nothing in the task table about the output... >> >> Daniel >> >> --