On Sep 12, 2006, at 11:17 PM, concurrency-interest-
[hidden email] wrote:
> Date: Tue, 12 Sep 2006 23:06:12 -0400
> From: "Tim Peierls" <[hidden email]>
> On 9/12/06, Dhanji R. Prasanna <[hidden email]> wrote:
>> If there are mission critical differences I certainly would not
>> trust them
>> to the same threadpool.
> Building that lack of trust into task submission code might also be a
> Maybe this is obvious to all, but here's a reminder: Sometimes the
> strategy is not to settle definitively on a particular strategy but to
> encapsulate the execution policy within an Executor or
> ExecutorService. That
> way, by changing the concrete type of an Executor and without
> affecting the
> client code, you can change your mind at deploy time about whether
> to use
> separate thread pools.
> Then you can measure the effectiveness of different strategies in
> instead of trying to reason in the abstract about which works better.
Well said. I found that developers preferred a PriorityBlockingQueue
with a custom Comparator to a FIFO queue ( https://
MessageComparator first differentiates by priority, then by age
(oldest first), then by something arbitrary but predictable. The
developers prefer it because of the predictability.
In practice, we get around needing to bound the size by answering,
"How will the system respond if the queue gets too big?"
PriorityBlockingQueue has a size() method, so we can monitor it. When
it gets too big or is growing too fast, we start more consumers or
throttle back the less important producers or redesign to make the
consumers more efficient. Throttling back the producers via blocking
is a heavy handed option; it might save us running out of memory but
would mean something else is broken.