Thanks for your response, 2012/8/12 Niphlod <niph...@gmail.com>
> Uhm, serializing part of the output to the table every n seconds - with > the output being a stream - would require a buffer/read/flush to update the > scheduler_run table that I'm not sure it's feasible: I'll look into that > but ATM I'm more concerned with other small issues of the Scheduler. > I don't know if it would work this way but I would be glad if you could give me some feedback (its actually just a proof of concept - but I did already test it a little): https://github.com/dhx/web2py/compare/scheduler_live_output > I'll definitely add to the feature-list the possibility to "recover" the > output from TIMEOUTted tasks. > Aaanyway - for both issues - the logging module (and not some random > prints) is the right tool for the job ^_^ . > Using the logging module is an option, but wouldn't I either end up writing to a file or to another table? > BTW: as of now I saw only a queue/task processor for node.js that reports > the "percentage" (i.e. every small bit of change "intra-execution" of the > task in the workers "bubbles" up to the queue manager). Could you pinpoint > me to a queue/task messaging implementation with this feature, if you saw > this feature implemented already ? > Well, actually I did not, but that doesn't mean a lot as I didn't have the requirement of a scheduler in a web framework until recently... > > 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 >> >> -- > > > > --
