Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1702 (closed defect: fixed)

Opened 9 years ago

Last modified 8 years ago

Scheduler doesn't ever shut down if interval_task was executing when interrupt sent

Reported by: xentac Owned by: Chris Arndt
Priority: low Milestone: 1.1.x bugfix
Component: TurboGears Version: 1.0.4.2
Severity: normal Keywords: confirmed, needs patch
Cc:

Description

If you ctrl-c a turbogears process that has interval_tasks running in it, the interval_tasks will continually be rescheduled forever.

Because Scheduler.stop() doesn't stop Tasks from Task.reschedule()ing, a running task can reschedule itself after the scheduler is supposed to be stopped.

The problem seems to be in the 1.0 and 1.1 branches.

Attachments

scheduler.patch Download (965 bytes) - added by chrisz 8 years ago.
Simple patch for not rescheduling after shutdown

Change History

comment:1 Changed 9 years ago by faide

  • Milestone changed from 1.5 to 1.1

comment:2 Changed 8 years ago by faide

Would you like to propose some patch ?

comment:3 Changed 8 years ago by xentac

It's been a while since I thought about this code...

But I think one of the problems was that there's no difference between not running and shutting down. If I want to shut down the scheduler, I don't ever want to reschedule anything.

You could make a Scheduler.shutdown method that set self.shuttingdown = True and everywhere that you check self.running you check self.shuttingdown also. If self.shuttingdown is True then don't execute anything (vs. queuing in the case of self.running).

Then in the startup module make it call scheduler._shutdown_scheduler() instead of scheduler._stop_scheduler().

If having another property doesn't seem like a good solution, make the state an Enum: "stopped", "running", "shuttingdown"

comment:4 Changed 8 years ago by xentac

I could probably write a patch if my explanation wasn't good enough.

comment:5 Changed 8 years ago by Chris Arndt

  • Priority changed from normal to low
  • Status changed from new to assigned
  • Owner changed from anonymous to Chris Arndt

Sorry, I can't reproduce this.

from turbogears import scheduler

def do_something():
    print "XXXXXXXXXXXXXXXXX Hello world."
    time.sleep(20)
    print "XXXXXXXXXXXXXXXXX Hello again."

scheduler.add_interval_task(action=do_something, taskname='do_something',
    initialdelay=0, interval=10)

Killing TH with Ctrl-C shuts down the scheduler normally. Can you post some code, which exhibits the problem?

comment:6 Changed 8 years ago by xentac

I think the difference in my code vs. this code is I was using the sequential scheduler, not the threaded one.

comment:7 Changed 8 years ago by Chris Arndt

Please post your actual code and don't keep me guessing. Thanks!

comment:8 Changed 8 years ago by xentac

scheduler.add_interval_task(taskname='Job Scheduler', action=do_something, initialdelay=10, interval=10, processmethod=turbogears.scheduler.method.sequential)

This is how I add the task. Right now, we're using 0.9a6 (I know, it sucks) but the scheduler code hasn't changed significantly since then.

If you still can't reproduce it, I will try creating a tg 1.1 project and reproducing it there.

comment:9 Changed 8 years ago by Chris Arndt

  • Keywords confirmed, needs patch added

Ok, now I can reproduce it. I'll look into it asap.

comment:10 Changed 8 years ago by Chris Arndt

  • Milestone changed from 1.1 to 1.1.x bugfix

I didn't have time to find a solution for this in time for the 1.1rc1 release. If you can provide a patch within next week, I might consider it for 1.1final but probably it will have to wait for 1.1.1.

comment:11 Changed 8 years ago by chrisz

I think the fix is very easy (see patch), or am I overlooking something?

Changed 8 years ago by chrisz

Simple patch for not rescheduling after shutdown

comment:12 Changed 8 years ago by Chris Arndt

Yes, this seems to fix it. I just didn't have the time to look more closely at this problem during the last release preparations. Can you please apply to all 1.x branches? Thanx

comment:13 Changed 8 years ago by chrisz

  • Status changed from assigned to closed
  • Resolution set to fixed

Applied in r6886.

Note: See TracTickets for help on using tickets.