activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "james (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMQ-4902) ineffective use of ThreadPoolExecutor
Date Mon, 25 Nov 2013 15:05:35 GMT
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)

Mime
View raw message