[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061107#comment-15061107 ] ASF subversion and git services commented on ARTEMIS-312: - Commit 0e8f2f39af666f50435b784c41c3d3767cfc4f7e in activemq-artemis's branch refs/heads/master from [~martyntaylor] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=0e8f2f3 ] ARTEMIS-312 Allow configurable of, and inject of client global thread pools > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053060#comment-15053060 ] clebert suconic commented on ARTEMIS-312: - >> JNDI would be appealing for anybody who doesn't want to put implementation >> classes in their code. Most users of ActiveMQ5 don't use JNDI as far as I know.. it exists for users who want independency.. but you could achieve the same with simple encapsulations on client's code. We will support it.. but I see more and more users going without JNDI. >> "...things get messed up as you would have only the last one affecting the >> setting." Can you clarify this point? Say you set the pool size through a connection factory property. if you have different settings from different instances you won't know which one would be respected. it's a static field so you can't use it through connection factory settings. > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053027#comment-15053027 ] Justin Bertram commented on ARTEMIS-312: JNDI would be appealing for anybody who doesn't want to put implementation classes in their code. I'm not sure what you mean by, "...things get messed up as you would have only the last one affecting the setting." Can you clarify this point? > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052967#comment-15052967 ] clebert suconic commented on ARTEMIS-312: - I think you only saw this issue because TCP flow control was broken before. And you were also opening lots of clients from a single VM, which is also not the idea... cases like this will definitely need tuning. If we make this tunable and part of the doc, I think we should be ok. > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052932#comment-15052932 ] Glaucio Melo commented on ARTEMIS-312: -- Quick note: Just saying a big number because a big number is better than infinite :D probably a smaller configuration than a M4 machine can crash before it reaches the value of 2500. Thanks! > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[
https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052907#comment-15052907
]
clebert suconic commented on ARTEMIS-312:
-
to me, JNDI is kind of deprecated for standalone.. .Why someone needs JNDI with
Artemis?
It's so easy to create a connection factory with just:
cf = new ActiveMQConnection("tcp://host:port");
You could say we make this as a property of the connection factory, but things
get messed up as you would have only the last one affecting the setting.
for that reason I think the best is to be a static property as a system
property for the JVM running. Or programmatically directly on the class
holding the 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052859#comment-15052859 ] Justin Bertram commented on ARTEMIS-312: [~clebertsuconic], if the client is using JMS then the value can be configured via jndi.properties or via an app server if that's being used. However, if the client is using the core API then they'd have to set it programmatically I think. > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052823#comment-15052823 ] clebert suconic commented on ARTEMIS-312: - 2500 max with a configuration option to go higher seems reasonable to me. this is a static thread pool, with no relation to any server start whatsoever. The only possible way to configure this would be a system property as far as I know. > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052622#comment-15052622 ] Glaucio Melo commented on ARTEMIS-312: -- Hi Justin / Clebert, Thank you for the valuable comments. Regarding documentation, we found the solution at the link aforementioned by you, my point here is to possibly get surprised with something else misconfigured and have to chase all the documentation to be aware about all the possible pitfalls according to the environment / platform we are putting Artemis. I'm happy to hear you haven't heard not too much from other customers, here we use to work with some big numbers (200 million messages per day) so, unfortunately huge volumes comes with big issues as well :( >From what I saw, using a Amazon M4 machine ( >https://aws.amazon.com/ec2/instance-types/ ) the client producer starts to >crash when we reached nearly 5000 active threads. That said and being >conservative, I would recommend something 50% less than that, putting >maxThreadPoolSize between [2000, 2500] Hope this helps! Thanks, Glaucio > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051748#comment-15051748 ] Justin Bertram commented on ARTEMIS-312: To Clebert's point, we can certainly add more configuration options for the client thread pools and even change the defaults (which I was trying to clarify in my first response to [~jmesnil]). Do you have any specific suggestions about what you would like to see changed here, [~Glaucio Melo]? > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051743#comment-15051743 ] Justin Bertram commented on ARTEMIS-312: Just to clarify regarding reading "all the documentation and details"... I'd simply say that if you noticed a threading issue then the natural place to look in the documentation would be the "[Thread Management|http://activemq.apache.org/artemis/docs/1.1.0/thread-pooling.html]"; chapter (which I linked previously). There's no need to read _all_ the documentation for that one issue. > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051735#comment-15051735 ] clebert suconic commented on ARTEMIS-312: - I agree that unbounded is not the best... We can go faster after a lot of changes.. so we can hit this faster... > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051125#comment-15051125 ] Glaucio Melo commented on ARTEMIS-312: -- Hi Justin, thanks for your comments. Yes, I did read this documentation link, right after we found what was happening with our platform :) Despite we are currently on hold due to a few other reasons, with this globalPools as true as default value, our platform was up and running just for a few minutes before crash (around 8 minutes). Also, due to time-management perspective, unfortunately this behaviour had caused a biased impression about Artemis at all. I know most of java frameworks need to be opened for configuration, but my point here isn't exactly on *where to change* or *where to read about*, but let as default a configuration which gives a room for dangerous consequences. Nevertheless, I'm pretty sure that's not everybody that would be available to read all the documentation and details (and I spent a lot of time doing that), and I know there is a disclaimer from my part on not trying harder on make it work properly - but in my vision, set a wide-opened-unrealistic configuration as default is error-prone for any framework which has intent to be prepared to go in production. Thanks! Glaucio > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15051019#comment-15051019 ] Justin Bertram commented on ARTEMIS-312: [~Glaucio Melo], did you try setting useGlobalPools = false and then setting then setting an appropriate threadPoolMaxSize for your use-case? You are not restricted to using the global, unlimited 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[ https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15050907#comment-15050907 ] Glaucio Melo commented on ARTEMIS-312: -- Hi folks, Due to this default behaviour from Artemis (letting a number of thread limited by Max_Integer) put us from Movile Brazil on hold with Artemis testings. When you have high throughputs from servers, the thread pool size is growing up very fast until reaches the machine memory resources, the whole system can't handle with this opened configuration. IMO, from a software / product development perspective, it's preferable to have some latency / delay when a resource pool is full instead of allocating resources indefinitely. Despite the fact we have cheap hardwares nowadays it doesn't justify on saying those are infinite. From now, we are still using Amazon SQS due to its high throughput but we are planning to keep going with these testings focused on thread pool resources, as soon as we have a chance to do it. Thanks, Glaucio > 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)
[jira] [Commented] (ARTEMIS-312) Artemis clients use by default an unbounded global thread pool
[
https://issues.apache.org/jira/browse/ARTEMIS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049330#comment-15049330
]
Justin Bertram commented on ARTEMIS-312:
> 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)
