You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems we can fall in a race condition. Several launches of this code display different outputs (I just added a log trace in scheduler.py, function //_real_add_job//)
Functionnal:
guestdev@guestdev-laptop:~/Projet/bac_a_sable/APScheduler-2.0.1$ python test_aps.py
INFO:apscheduler.threadpool:Started thread pool with 0 core threads and 20 maximum threads
INFO:apscheduler.scheduler:Scheduler started
DEBUG:apscheduler.scheduler:Looking for jobs to run
DEBUG:apscheduler.scheduler:No jobs; waiting until a job is added
DEBUG:apscheduler.scheduler:Adding real job with wakeup: True
INFO:apscheduler.scheduler:Added job "job_function (trigger: cron[minute='*/2'], next run at: 2011-06-20 13:32:00)" to job store "default"
DEBUG:apscheduler.scheduler:Looking for jobs to run
DEBUG:apscheduler.scheduler:Next wakeup is due at 2011-06-20 13:32:00 (in 100.794154 seconds)
Race condition, which leads to multiple fires of the same job:
guestdev@guestdev-laptop:~/Projet/bac_a_sable/APScheduler-2.0.1$ python test_aps.py
INFO:apscheduler.threadpool:Started thread pool with 0 core threads and 20 maximum threads
INFO:apscheduler.scheduler:Scheduler started
DEBUG:apscheduler.scheduler:Adding real job with wakeup: True
DEBUG:apscheduler.scheduler:Looking for jobs to run
INFO:apscheduler.scheduler:Added job "job_function (trigger: cron[minute='*/2'], next run at: 2011-06-20 13:32:00)" to job store "default"
DEBUG:apscheduler.scheduler:Next wakeup is due at 2011-06-20 13:32:00 (in 99.725313 seconds)
DEBUG:apscheduler.scheduler:Looking for jobs to run
DEBUG:apscheduler.scheduler:Next wakeup is due at 2011-06-20 13:32:00 (in 99.724925 seconds)
I can't reproduce the bug if I add a job before starting the scheduler.
Original comment byAlex Grönholm (Bitbucket: agronholm, GitHub: agronholm):
This output does not actually demonstrate multiple fires of the same job.
Can you reproduce that? The scheduler waking up more than once is a non-issue.
Nervermind, I am such a dumbass...
I was mislead by the scheduler waking up twice in my example, that I did not see I messed up my cronjob (not the one attached as example in my first post):
Originally reported by: chemicalstorm (Bitbucket: chemicalstorm, GitHub: chemicalstorm)
Using the following code:
It seems we can fall in a race condition. Several launches of this code display different outputs (I just added a log trace in scheduler.py, function //_real_add_job//)
Functionnal:
Race condition, which leads to multiple fires of the same job:
I can't reproduce the bug if I add a job before starting the scheduler.
The text was updated successfully, but these errors were encountered: