[jira] [Updated] (AMQ-4902) ineffective use of ThreadPoolExecutor

["Matt Pavlovich (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-4902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Pavlovich updated AMQ-4902:
--------------------------------
    Fix Version/s: NEEDS_REVIEW

> 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
>             Fix For: NEEDS_REVIEW
>
>
> 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
(v8.3.4#803005)