[
https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051654#comment-15051654
]
Justin Bertram commented on ARTEMIS-312:
----------------------------------------
As I'm sure you understand, a message broker is a complex piece of software and
the default configuration will not be optimal for every particular use-case.
The bottom line here is that certain choices must be made. Here's a simple
example. In earlier versions of HornetQ using Netty 3.x we had to choose
between using blocking IO by default or non-blocking IO by default for remote
clients. Blocking IO would provide the lowest latency for a small number of
connections, but wouldn't scale well (and would be "dangerous" under heavy load
due to all the threads required to service remote connections). Non-blocking
IO would scale well but with a small latency penalty. We chose to go with
blocking IO by default and documented both configuration options clearly. The
same basic scenario plays out hundreds of different ways across the broker's
configuration.
I've been working with HornetQ for a number of years now, and I don't often
hear users complain about the default thread pool configuration. That leads me
to believe that the default thread pool configuration is likely suitable for
most use-cases. We've tried to make the defaults _sensible_, but of course
even that is up for debate depending on your perspective. You're certainly
free to think that the default configuration is "wide-opened-unrealistic," but
I hope you'd also grant there are other reasonable opinions on that. The
definition of "production ready" is as varied as the number of production
environments.
> 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)
