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 06:53:25 GMT


ASF GitHub Bot commented on ARTEMIS-485:

GitHub user bgutjahr opened a pull request:

    ARTEMIS-485: Use unbounded client thread-pool by default

    I changed the ActiveMQClient code to use an unbounded cached thread pool by default, as
it was the case with Artemis 1.1.0 and before.
    Bounded fixed-size thread pools create and keep all configured client threads, which can
negatively impact client behavior due to additional memory consumption. Even the recently
made change to set default max size based on the number of cores won't help on modern multi-core
    I also had to remove the capability to dynamically change the thread pool max size, as
this would not work if changing the size of an unbounded cached thread pool (due to different
blocking queue classes). So after changing the max size, the caches have to cleared to get
new caches created.
    In addition, I fixed some API flaws (public writable fields and not checking for injected
null thread pools).

You can merge this pull request into a Git repository by running:

    $ git pull thread_pools

Alternatively you can review and apply these changes as the patch at:

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #468
commit 54b553465ba49152413a3b36c482584adc102968
Author: Bernd Gutjahr <>
Date:   2016-04-15T06:20:05Z

    ARTEMIS-485 Use unbounded client thread pool by default
    Set default global client thread pool size back to -1,
    and adapted code to handle -1 correctly to configured an unbounded (cached)
    thread pool.
    In addition, I the capability to reconfigure the max pool size of existing
    thread pools, because the global thread pool can either be an unbounded
    cached pool, or a bounded fixed size pool. These 2 kinds of pool also
    differ in the used blocking queue, and cannot be converted into each other.

commit 2a4ff199b1732ec3aabde71174138594322e5259
Author: Bernd Gutjahr <>
Date:   2016-04-15T06:58:15Z

    ARTEMIS-485 Updated related comments
    Corrected code comments according to previous changed.

commit 2f20199d1929319cc2e31cfd176ca6b9453c434b
Author: Bernd Gutjahr <>
Date:   2016-04-15T07:14:30Z

    Changed public fields in ActiveMQClient to private and added getters.
    Exposing fields for thread pool sized allow to modify them in undesired ways.
    I made these fields private and added corresponding getter methods.
    In addition, I renamed the field 'globalThreadMaxPoolSize'
    to 'globalThreadPoolSize' to be more consistent with the
    'globalScheduledThreadPoolSize' field name.
    I also adapted some tests to always call clearThreadPools after
    the thread pool size configuration has been changed.

commit 0dc7dd20f42cd38f8868bc17696d08796ee8424c
Author: Bernd Gutjahr <>
Date:   2016-04-15T11:54:09Z

    Protect against injecting null as thread pools
    ActiveMQClient.injectPools allowed null as injected thread pools.
    The effect was that internal threads pools were created,
    but not shutdown correctly.


> 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