james created AMQ-4902:
--------------------------
Summary: ineffective use of ThreadPoolExecutor
Key: AMQ-4902
URL: https://issues.apache.org/jira/browse/AMQ-4902
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
(v6.1#6144)
