[
https://issues.apache.org/jira/browse/AMQ-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167154#comment-15167154
]
ASF subversion and git services commented on AMQ-6184:
------------------------------------------------------
Commit ca5912d9fad036a6d9c59e49a3273c5001e0115e in activemq's branch
refs/heads/master from [~dejanb]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ca5912d ]
https://issues.apache.org/jira/browse/AMQ-6184 - improve nio transport
scalability; get back core pool size
> 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)
