During the QUARTZ-13 work, it looks like the check in runInThread() that waits to make sure the previous next runnable has been assigned a worker thread before assigning the new next runnable has been removed. This leads to a race condition (which I ran into) where a nextRunnable gets overwritten by the next in line before it can be processed.

I think this also means the nextAvail count is not being calculated correctly, because for this overwriting case to have been allowed in my sample app with only one worker thread, it must have thought for both triggers that there was a thread available. (This makes sense with the worker thread being the one to decrement the availCount).

I leave this up to you James what you think will be the best way to handle this case since you are already so familiar with the threadpool and related issues (the availCount tracking means it is more complicated than just adding that original loop back in unfortunately).

I will also attach my test case which revealed the problem (when I ran it under the eclipse debugger). Another easy way to reproduce it presumably is to just put a breakpoint in the worker threads to simulate them being slow...)