[concurrency-interest] Bounded Task Queue for ScheduledThreadPoolExecutor

Doug Lea dl at cs.oswego.edu
Wed Apr 24 07:14:11 EDT 2019


On 4/23/19 2:37 AM, Volkan Yazıcı via Concurrency-interest wrote:
> Hello,
> 
> Given a ScheduledThreadPoolExecutor (STPE) with a set of slow consumers,
> the unbounded task queue constitutes the perfect disguise for
> backpressure-related problems. Producers just keep on pushing tasks to
> the point that 1) growing queue starts choking memory, 2) almost all
> pending time-sensitive tasks become obsolete when they are assigned to a
> thread to get executed, and 3) even relatively cheap tasks starve to
> death for no good reason. To the best of my knowledge, unfortunately,
> STPE does accept neither a bound, nor a custom queue in its ctor, even
> though the internally used ThreadPoolExecutor (TPE) perfectly allows
> that[1]. To work around the problem, I create my own
> ScheduledExecutorService where time-sensitive tasks are delegated to an
> internal STPE and the rest to a TPE. That being said, I would rather
> prefer STPE to just accept a custom implementation or a bound for the
> task queue it employs.

STPE started out (long ago, pre-release) allowing custom queues,
defaulting to DelayQueue. This was changed to use an internal
specialization of DelayQueue to allow cleanup of cancelled tasks, which
helps significantly in networking applications in which timeout
callbacks rarely turn out to be needed.

At this point there is no reasonable path to reinstating a custom queue
option. However, it would be possible to add yet another configuration
method setMaximumQueueSize, which would cause a
RejectedExecutionException if exceeded.

We worry when adding such methods about unknown interactions with other
configuration methods and constructors, leading to future bug reports.
Which I think has happened every time we have added one.

In the mean time you could get most of this effect at reasonable cost by
wrapping STPE within another Executor that rejects when
stpe.getQueue().size() exceeds a threshold.

-Doug




More information about the Concurrency-interest mailing list