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 Tue, 19 Apr 2016 09:59:25 GMT


ASF GitHub Bot commented on ARTEMIS-485:

Github user mtaylor commented on the pull request:
    @bgutjahr Thanks for the reply.
    Yes.  You are right we should get the documentation updated accordingly and explain the
pro's and cons of each approach, fixed, unbounded.  
    With regards to heap size, I am trying to figure out how each thread manages to increase
the heap by 500MB. this seems huge, if this is the case we need to figure out what is causing
this.  Perhaps sending lots of large messages concurrently could cause this?  Though if this
is the case unbounded pool probably wouldn't help...  Might you mean stack space by any chance?
 If so this does seem like a very high number and I'd recommend exploring why this is set
so high.
    Yes I see the issue with timeout.  What you described was my original concern the first
time round which is why I left it out.  If you decrease the timeout further you'll likely
get a performance hit, as you'll be constantly creating new threads (which with large stack
size would be even more costly).
    I think what we are missing with regards to defaults, is some performance numbers, really
these are just guesses, looking mostly at what Netty does.  I'm interested in your use case.
 Particularly understanding why the heap grows so large, because I think this is something
that needs addressing.  Do you have any more info on this?

> 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