trigger twice or thrice

[robfig]

trigger twice or thrice

[robfig]

Please clarify your issue. Are you finding the job is triggered too often, or not often enough?

[rbredlau]

I am seeing this as well on Windows Server 2003. My program simply prints the schedule and the elapsed number of seconds since it was last fired.

I am using the same three schedules on each system:

• */5 * * * * *
• */20 * * * * *
• @every 10s

Windows Server 2003 / go version go1.6.3 windows/386
The first six entries or so were all blurted out at once as soon as the program started; so the Job implementation is being fired multiple times. The @every 10s fires a little too soon but does work and you can see all the others that are every 5 or every 20 seconds came out multiple times before the single @every 10s.

cron-exec [*/5 * * * * *]: Time since last: 2
cron-exec [*/5 * * * * *]: Time since last: 1
cron-exec [*/5 * * * * *]: Time since last: 4
cron-exec [*/20 * * * * *]: Time since last: 7
cron-exec [*/5 * * * * *]: Time since last: 0
cron-exec [*/20 * * * * *]: Time since last: 0
cron-exec [*/5 * * * * *]: Time since last: 0
cron-exec [*/20 * * * * *]: Time since last: 0
cron-exec [*/5 * * * * *]: Time since last: 0
cron-exec [*/20 * * * * *]: Time since last: 0
cron-exec [*/5 * * * * *]: Time since last: 0
cron-exec [*/20 * * * * *]: Time since last: 0
cron-exec [*/5 * * * * *]: Time since last: 0
cron-exec [*/20 * * * * *]: Time since last: 0
cron-exec [*/5 * * * * *]: Time since last: 0
cron-exec [*/20 * * * * *]: Time since last: 0
cron-exec [*/5 * * * * *]: Time since last: 1
cron-exec [*/20 * * * * *]: Time since last: 1
cron-exec [@every 10s]: Time since last: 9

debian / go version go1.7.1 linux/386
This is working correctly.

cron-exec [*/5 * * * * *]: Time since last: 3
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [@every 10s]: Time since last: 10
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [*/20 * * * * *]: Time since last: 18
cron-exec [@every 10s]: Time since last: 10
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [@every 10s]: Time since last: 10
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [*/20 * * * * *]: Time since last: 20

Windows 10 / go version go1.6.2 windows/386
This also works correctly.

cron-exec [*/5 * * * * *]: Time since last: 1
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [@every 10s]: Time since last: 10
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [*/20 * * * * *]: Time since last: 11
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [@every 10s]: Time since last: 10
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [@every 10s]: Time since last: 10
cron-exec [*/5 * * * * *]: Time since last: 5
cron-exec [*/20 * * * * *]: Time since last: 20
cron-exec [*/5 * * * * *]: Time since last: 5

As far as I'm aware go 1.6.3 is the latest supported on Win2003. The older go 1.6.2 works but on a newer version of Windows. I suspect this is some sort of problem related specifically to the older Windows OS. I wouldn't imagine you'd want to support a 13 year old dead OS but you might want to make a mention on the project's homepage.

I haven't tested any other schedule (such as * */5 * * * *) on Win2003. My end goal is a daily schedule which might work on Win2003 - or the machine I deploy to might be a newer Windows anyways.

[rbredlau]

Here is the git diff output that fixes this on Windows 2003.

diff --git a/cron.go b/cron.go
index f8d325d..1f0772d 100644
--- a/cron.go
+++ b/cron.go
@@ -183,6 +183,9 @@ func (c *Cron) run() {
                timer := time.NewTimer(effective.Sub(now))
                select {
                case now = <-timer.C:
+                       if now.Sub(effective) < 0 {
+                               continue
+                       }
                        now = now.In(c.location)
                        // Run every entry whose next time was this effective time.
                        for _, e := range c.entries {

The problem is that if the sleep duration is very small, around 1ms, then the sleep may return immediately. The same sleep time may then be calculated and return immediately again. And this can happen a few times. All I did is make sure that the duration that passed between now and effective was >= 0; i.e. that some form of sleep actually occurred.

[robfig]

Sorry for the trouble - the updated waiting mechanism on the v3 branch works for this by verifying the time has arrived for the job:

		select {
		case now = <-timer.C:
			now = now.In(c.location)
			// Run every entry whose next time was less than now
			for _, e := range c.entries {
				if e.Next.After(now) || e.Next.IsZero() {
					break
				}
				go c.runWithRecovery(e.Job)
				e.Prev = e.Next
				e.Next = e.Schedule.Next(now)
			}

Please let me know if you see any remaining problems on the v3 branch. Thank you