activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-6184) Improve nio transport scalability
Date Wed, 28 Sep 2016 09:11:20 GMT

    [ https://issues.apache.org/jira/browse/AMQ-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15528996#comment-15528996
] 

ASF subversion and git services commented on AMQ-6184:
------------------------------------------------------

Commit 08695ab30306307aced0d2d51b1755bc6e29081a in activemq's branch refs/heads/master from
[~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=08695ab ]

https://issues.apache.org/jira/browse/AMQ-6184 - add workQueueCapacity config property default
to 0 where a value > 0 swaps out the dsynchQ for a capicity limited blocking queue. This
allows the core pool to grow on demand as before but also allows work to be queued when necessary


> Improve nio transport scalability
> ---------------------------------
>
>                 Key: AMQ-6184
>                 URL: https://issues.apache.org/jira/browse/AMQ-6184
>             Project: ActiveMQ
>          Issue Type: Improvement
>    Affects Versions: 5.13.0
>            Reporter: Dejan Bosanac
>            Assignee: Dejan Bosanac
>             Fix For: 5.14.0
>
>
> NIO transport uses unbounded thread pool executor to handle read operation. Under large
number of connections and load, this could lead to large number of threads and eventually
OOM errors. Which is the exact problem that nio transport is supposed to solve. Some work
has been done in [AMQ-5480], to make this configurable, but there's still more work to make
it more robust. Creating a fixed thread pool with a queue in front gives much better results
in my tests.
> Additionally, the same thread pool is used for accepting connections ([AMQ-5269]). This
can lead to the broker not being able to accept new connections under the load. I got much
better results when experimenting with implementing acceptor logic directly and handling it
in the same thread (without reintroducing the old problem). 
> With these two improvements in place, the broker accept and handle the number of connections
up to the system limits.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message