Hi,
Looking at the QuartzThreadPool#blockForAvailableThreads impl [1]
---
@Override
public int blockForAvailableThreads() {
return this.executor.getConfiguration().getMaxPoolSize() -
this.executor.getConfiguration().getQueueSize();
}
---
Above implementation does not "block" as per contract [2]
---
Determines the number of threads that are currently available in in
the pool. Useful for determining the number of times
runInThread(Runnable) can be called before returning false.
The implementation of this method should block until there is at least
one available thread.
---
Further looking at code its not clear if
executor.getConfiguration().getQueueSize() returns the current size as
it appears to be set only at time of config and does not indicate the
true size of current Sling threadPool implementation
Looking at Quartz flow its not clear what impact it would have. But
per contract this looks incorrect.
Thoughts?
Chetan Mehrotra
[1]
https://github.com/apache/sling/blob/trunk/bundles/commons/scheduler/src/main/java/org/apache/sling/commons/scheduler/impl/QuartzScheduler.java#L506
[2]
http://www.quartz-scheduler.org/api/2.2.1/org/quartz/spi/ThreadPool.html#blockForAvailableThreads()
