[
https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049330#comment-15049330
]
Justin Bertram edited comment on ARTEMIS-312 at 12/9/15 8:22 PM:
-----------------------------------------------------------------
> This default global pool looks misconfigured. If a Artemis clients has a lot
> of activity it is actually possible that threads are deleted from the pool
> and added back.
Can you elaborate on this possible use-case? Are you talking about, for
example, a client with short, heavy bursts of activity where a lot of threads
may be created in the cached thread pool and then would time-out after 60
seconds and be removed only to have threads be created again during the next
burst of activity?
Would you prefer the ability to define the "core" size of this thread pool so
that a certain number of threads would always be retained in the pool?
> If the Artemis client is using a "non-global" pool, {{threadPoolMaxSize}} is
> used to create a newFixedThreadPool. So this property defines the actual size
> of the pool, not a max size.
The value for threadPoolMaxSize is passed as the first parameter to
java.util.concurrent.Executors#newFixedThreadPool(int,
java.util.concurrent.ThreadFactory) which ultimately defines _both_ the "core"
size and the "max" size of the thread pool.
Is your concern here that it's not clear based on the name of
{{threadPoolMaxSize}} that it applies only to the "non-global"?
BTW, much of this is discussed in the documentation (e.g.
[http://activemq.apache.org/artemis/docs/1.1.0/thread-pooling.html])
was (Author: jbertram):
> This default global pool looks misconfigured. If a Artemis clients has a lot
> of activity it is actually possible that threads are deleted from the pool
> and added back.
Can you elaborate on this possible use-case? Are you talking about, for
example, a client with short, heavy bursts of activity where a lot of threads
may be created in the cached thread pool and then would time-out after 60
seconds and be removed only to have threads be created again during the next
burst of activity?
Would you prefer the ability to define the "core" size of this thread pool so
that a certain number of threads would always be retained in the pool?
> If the Artemis client is using a "non-global" pool, {{threadPoolMaxSize}} is
> used to create a newFixedThreadPool. So this property defines the actual size
> of the pool, not a max size.
The value for threadPoolMaxSize is passed as the first parameter to
java.util.concurrent.Executors#newFixedThreadPool(int,
java.util.concurrent.ThreadFactory) which ultimately defines _both_ the "core"
size and the "max" size of the thread pool.
> Artemis clients use by default an unbounded global thread pool
> --------------------------------------------------------------
>
> Key: ARTEMIS-312
> URL: https://issues.apache.org/jira/browse/ARTEMIS-312
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
> Affects Versions: 1.1.0
> Reporter: Jeff Mesnil
> Assignee: Justin Bertram
>
> While investigating some performance issues, we noticed that Artemis clients
> (including MDBs) use by default a "global" pool by creating a cached thread
> pool with 0 core pool size, Integer.MAX_VALUE max size and 60s keep alive.
> This default global pool looks misconfigured. If a Artemis clients has a lot
> of activity it is actually possible that threads are deleted from the pool
> and added back.
> Related to this, Artemis defines a threadPoolMaxSize attribute if the client
> is not using a global pool. But the property does not seem to be well name.
> If the Artemis client is using a "non-global" pool, this property is used to
> create a newFixedThreadPool. So this property defines the actual size of the
> pool, not a max size.
> As a comparison, the "global" scheduled thread is instantiating with a 5 core
> pool size.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
