[
https://issues.apache.org/jira/browse/AMQ-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13831531#comment-13831531
]
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: 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)
