activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-485) Global client thread pool is not unbounded by default
Date Mon, 18 Apr 2016 18:32:25 GMT


ASF GitHub Bot commented on ARTEMIS-485:

Github user mtaylor commented on the pull request:
    @bgutjahr This all look good to me, except the unbounded default pool setting :D, for
reasons I mentioned above.  We have had people complaining that it grows out of control under
high load.  Which as I mentioned is the original reason for the change.   
    How about we add the setting to time out threads in the pool as shown in the link above
but keep the default the same.  Using a multiplier of the cores is a reasonably standard way
to calculate defaults and it's usually reflection on the system resource, but we could easily
change this, if there is a lot of objection.  This is also how Netty instantiates some of
it's thread pools.
    I wonder if there is a thread pool policy that could prevent the pool growing too large,
but not behave like a fixed pool.  Ideally we'd like to pool to grow organically, up to a
certain number.  I was unable to find an appropriate policy using ThreadPoolExecutor in the
 But perhaps there's another way to handle this?  Any suggestions?

> Global client thread pool is not unbounded by default
> -----------------------------------------------------
>                 Key: ARTEMIS-485
>                 URL:
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 1.2.0
>            Reporter: Bernd Gutjahr
> With the change #263, "Allow configurable size for client global pools", the default
global client thread pool has been changed from an unbounded thread pool to a fixed size pool.
In addition, that changed made it impossible to configure the thread pool as unbounded.
> With the unbounded thread pools, client threads are created on demand, but get cleared
after an idle time of one minute. In normal client operations, there weren't many client threads.
With the change to a fixed size thread pool, the pool quickly fills up with the configured
number of client threads, which never go away.
> I have seen that each thread had ~500kB allocated, which leads to 250MB  with the default
of 500 threads.
> Therefore, I would like to have the default changed back to -1 (= unbounded thread pool),
as it also documented in the "Client-Side Thread Management" chapter of the user documentation.
The code also needs to be fixed to handle -1 correctly, as it currently changes it to 2.

This message was sent by Atlassian JIRA

View raw message