I don't know the answer, but are you experiencing problems in this area?
Carsten
Chetan Mehrotra wrote
> 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()
>
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
