3.0.0-alpha1 DisallowConcurrentExecution Job with short interval only executes on IdleWaitTime

[ceastwood]

I haven't gotten a chance to confirm that the behavior is incorrect but I thought discussing it may help.

I'm testing the 3.0.0-alpha1 scheduler, and it seems that if the scheduler is very lightly loaded (only a few triggers set), and has a job w/ disallowConcurrentExecution that has a very quick simpletrigger (1000ms)-- the scheduler is falling asleep and not firing the job until the idleWaitTime expires (so initial fire, then every 30s on default). If I remove the disallow flag from the job, it will fire every interval properly.

Of course changing the IdleWaitTime lower helps but I was under the impression the scheduler should be aware that the trigger it just fired is scheduled before that idle interval expires so that it would wake up to fire the next schedule.

[lahma]

Could you please provide more details. I'm unable to reproduce this with neither RAMJobStore or AdoJobStore. I tried running two triggers against single job that had DisallowConcurrentExecution attribute and everything was running in a timely manner. Does this happen with Quartz 2.x what kind of thread pool configuration you have etc?

[ceastwood]

Logfile.txt
QTZ-396_Sample.zip

I haven't ran 2.x-- went straight for the alpha for the async ;D I believe the example program should help with showing my configuration. Attached is a logfile and the example program, the example job will log a warning if the elapsedSinceLastRun is > 1100ms (job scheduled for 1s). The scheduler doesn't indicate a misfire either.

2016-08-21 14:35:27.204 [Debug] [Quartz.Core.JobRunShell] Calling Execute on job Group.TroubleJob
clip
2016-08-21 14:35:54.423 [Debug] [Quartz.Core.JobRunShell] Calling Execute on job Group.TroubleJob
2016-08-21 14:35:54.424 [Warning] [QTZ_396_Sample.Jobs.TroubleJob] ElapsedSinceLastRun : 00:00:26.7174748

The app.config will need your SQL connection string

[lahma]

Thank you, this will help me to investigate.

[lahma]

I have pushed a fix to master, there was a nasty problem with thread local storage use that really doesn't play out anymore with async world. Could you test building the binaries yourself and verify the fix?

[ceastwood]

I was actually just reading your commit details from my phone. I did notice the lock owner and callcontext issues when playing with the source too.

I will pull the update and test on my end at some point today.

Thanks

[smbecker]

Any chance that we could get this pushed to nuget? This was a pretty nasty issue.

[ceastwood]

The few job types that I have implemented are working just fine, thanks again

[lahma]

@ceastwood thanks for confirming!

@smbecker I'll push a release for alpha 2 later this evening, I'll ping pack here too then.

[lahma]

I went ahead and pushed the alpha 2 packages to NuGet feed so they should be available now. I'll do proper announcements and web updates later.

[smbecker]

Awesome, thanks