If you're really returning at the end (not near, the actual end) how many records were added, the very "returned" data would cause your task to be COMPLETED. If you're printing near the end, and then returning something, then the task TIMEOUTing is probably stuck trying to flush stdout/stderr buffers or serializing the result to json. The issue on stdout/stderr buffer is more common on Windows environments, and it's an issue of the multiprocessing module rather than the scheduler itself: try to limit those (don't use print instead of a proper logging, and limit as much as you can external programs littering your buffer) and you'll have your "issue" fixed.
On Monday, November 23, 2015 at 9:50:38 PM UTC+1, Benson Myrtil wrote: > > Hey guys > > I have the scheduler running a task. The task hits an API, downloads data > and imports into our database using MySQL LOAD DATA INFILE. There are > several API endpoints we hit so I use the same base code to make the > request, and pass in a variable that tells the system which endpoint to hit. > > Whats weird is i am noticing the scheduler is timing out even though it > appears the task has completed. At the very end I have the task return a > statement detailing how many records were added to the database. From the > scheduler_run, I can see that the return statement does tell me how many > records were entered which is the last line of the code yet the system > shows it as TIMEOUT instead of COMPLETED. > > Any reason why this would occur? > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
