I am not sure that your statement that Job2 has no chance to run again is true in theory, but in practice you are probably right.
Remove your [DisallowConcurrentExecution] attribute, and you will probably see more occurrences of Job2.
Alter your inheritance so that Job1 and Job2 are different job classes and you might see more occurrences of both.
But ultimately, your 1 thread job pool is probably an artificial constraint one wouldn't normally see in production except in special situations.
Also, your job scheduling is identical on both jobs (same start time, same interval, same duration, same priority). So each time the scheduler brings the jobs up for submission to your single-thread thread pool, it has no criteria that differ between the two jobs other than the order in which they were scheduled. And in that scenario, it always goes with the first one scheduled. I hit this same situation myself when I started playing with the Quartz engine last week.
On Friday, June 9, 2017 at 8:54:57 AM UTC-4, Олександр Калиняк wrote:
Under heavy load some jobs can not be executed.
Let me explain on simple example.
I have job which imitate long running computation: