activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] [Commented] (AMQ-4902) ineffective use of ThreadPoolExecutor
Date Mon, 25 Nov 2013 15:15:36 GMT


Daniel Kulp commented on AMQ-4902:

As a note:  CXF's workqueues end up using a hacked subclass of the oracle ThreadPoolExecutor
to get around this same problem.   Could think about stealing some code from there.

> ineffective use of ThreadPoolExecutor
> -------------------------------------
>                 Key: AMQ-4902
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.9.0
>            Reporter: james
>            Priority: Minor
> I noticed that the BrokerService uses a default ThreadPoolExecutor configured with a
"variable" number of threads (1-10) and an unbounded queue (LinkedBlockingQueue).  The way
that the oracle ThreadPoolExecutor is implemented makes this configuration very ineffective,
as it will never use more than 1 thread.  The basic strategy in the ThreadPoolExecutor is
to add threads until it gets to the "core" pool size (in this case 1) then prefer queueing.
 only when an offer to the queue fails will threads be added beyond the core pool size.  since
the LinkedBlockingQueue is unbounded, offer will never fail and no more threads will be added.
> There are no great strategies for getting a good variable sized thread pool combined
with an unbounded queue using the ThreadPoolExecutor.  2 possible solutions are:
> * Set min to the max and allow core threads to timeout
> * using a "lying" blocking queue which initially rejects offers, but then use a rejected
execution handler which puts the elements on the queue.  this forces threads to be added up
to the max before tasks get queued
> note that i noticed this in the broker, but i believe this pattern is used in other activemq
classes as well.

This message was sent by Atlassian JIRA

View raw message