[
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)
