Github user bgutjahr commented on the pull request:
https://github.com/apache/activemq-artemis/pull/468#issuecomment-211768214
**@mtaylor** I can understand the issue of an unbounded number of threads.
So leaving the default to a fixed thread pool is not an issue for me, as long
as we can change it back to unbounded. In that case, I would suggest to also
adapt the user documentation accordingly. I was under the - obviously wrong -
impression that changing the default to a fixed size was just a side effect of
the useful enhancement to configure the global thread pool.
In our application, I have seen each client thread to have ~500MB memory
allocated. With the default of 500, this consumed 250GB heap space. On my 32
core system, which the new default of 8*cores, this would still be 125GB. At
the end, this caused our process to go into constant garbage collection and
resulted in a big performance impact. As we use JMS but for a relativ low
message volume, we never have more than a few client threads actively running.
Thus we have never seen an issue with the unbounded thread pool.
I wonder whether the default number of threads should be reduced further,
but I don't really know what a good default would be. I guess this highly
depends on the application.
Maybe the the amount of memory that is allocated by idle threads could be
reduced and the whole issue would go ways. I didn't investigate that area.
I had also looked that the JDK ThreadPoolExecutor. It looks like it doesn't
allow to behave like a cached pool, but with a limited number of threads. One
option would be to implement a new thread pool that combines there two
paradigms.
I also had a look a the allowCoreThreadTimeOut option. But even then the
pool prefered to create new threads before reusing existing. With a 1 minute
timeout and a rate of 10 messages per second, which can easily be handled by a
small number of threads, we still got 500 threads in the pool. The only
different was that these threads timed out after I stopped sending messages.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
