ok, seems more a goal of a workflow engine than a task queue, but I'll see what can be done.
On Monday, March 11, 2013 10:54:10 PM UTC+1, dlypka wrote: > > a supervsior may decide to kill a task started by one of his team members. > > On Mon, Mar 11, 2013 at 4:50 PM, Niphlod <nip...@gmail.com > <javascript:>>wrote: > >> "business condition" like ???? >> it seems a poor design to have a task, than watch it and if it "hangs for >> some reason" kill it abruptly not based on "task started a while ago" >> >> PS: are you on windows ? signal management on win poses a lot of >> limitations. >> >> >> On Monday, March 11, 2013 10:27:17 PM UTC+1, dlypka wrote: >>> >>> timeout does not handle the case where it is discovered that the task >>> needs to be stopped ASAP due to a business condition. >>> For example the remote server may have limited connections available so >>> if a task runs into trouble, the process needs >>> to be killed ASAP to release the precious remote connection. That is >>> the case in my application. >>> >>> Even with a while loop, there will have to be a way get the win32 >>> process id of the python task for a given worker so the right one >>> can be killed. >>> >>> Looks like a better solution is for the task to have its own manager >>> thread that can listen for kill requests. >>> i.e. the scheduler tasks need to be written using a standard piece of >>> scaffolding code to provide fine-grained task management. >>> >>> On Monday, March 11, 2013 3:27:35 PM UTC-5, Niphlod wrote: >>>> >>>> having a single worker for each task can be daunting (well, you could >>>> wrap web2py.py -K appname in a never-ending loop so it's restarted as soon >>>> as it gets killed).... >>>> #!/bin/sh >>>> while true >>>> do web2py/web2py.py -K yourapp >>>> echo 'killed, restarting in a bit' >>>> sleep 2 >>>> done >>>> >>>> but I'm curious about your use-case. Why do you need to terminate a >>>> RUNNING task (that can't be accomplished using the timeout parameter)? >>>> >>>> >>>> On Monday, March 11, 2013 9:18:48 PM UTC+1, dlypka wrote: >>>>> >>>>> Thanks for the quick reply. >>>>> I suppose a workaround is to have a separate worker for each task. >>>>> The I can TERMINATE the worker. >>>>> >>>>> A suggestion: can you suggest some standard python scaffolding to >>>>> include in each >>>>> task function to make it listen for a kill signal / message? >>>>> >>>>> On Monday, March 11, 2013 3:05:21 PM UTC-5, Niphlod wrote: >>>>>> >>>>>> once the task is inserted you should not change it's values unless >>>>>> its in the QUEUED status (technically the ASSIGNED works too, but it's >>>>>> NOT >>>>>> recommended). >>>>>> there's no way for the scheduler to terminate a specific task once >>>>>> the task is started, unless you KILL the worker (setting the worker to >>>>>> TERMINATE will kill the worker as soon as the RUNNING task is finished). >>>>>> PS: if you need to execute a task n times, use the repeat argument. >>>>>> using time.sleep(something) in a task has the side-effect of NOT >>>>>> returning >>>>>> to the main loop to execute potentially new QUEUED tasks (every >>>>>> scheduler >>>>>> process is allowed to process a single task at a time). >>>>>> if you need to limit the time the task runs, use the timeout >>>>>> parameter. >>>>>> >>>>>> If something is not clear please ask. >>>>>> >>>>>> On Monday, March 11, 2013 8:04:52 PM UTC+1, dlypka wrote: >>>>>>> >>>>>>> >>>>>>> I need a way to terminate a specific Scheduled Task while it is >>>>>>> RUNNING. >>>>>>> I tried using Admin Database Admin to update the >>>>>>> scheduler_task.stop_time to a time close to now while it was running. >>>>>>> But the task continued for several more minutes and COMPLETED its >>>>>>> normal 5 minute run. >>>>>>> The task calls time.sleep(300) to make it run for 5 minutes. >>>>>>> >>>>>>> I guess the Scheduler is not looking at the db values every 3 >>>>>>> seconds. >>>>>>> Is it just checking the in memory task object properties? >>>>>>> >>>>>>> Is there a way to update the in memory object properties of a task >>>>>>> while it is running? >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>> -- >> >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "web2py-users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/web2py/7-ZOS_In8IU/unsubscribe?hl=en. >> To unsubscribe from this group and all its topics, send an email to >> web2py+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- --- 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/groups/opt_out.
