[
https://issues.apache.org/jira/browse/AMQ-6184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-6184.
-----------------------------
Resolution: Fixed
Fix Version/s: (was: 5.14.0)
5.15.0
We need the best of both worlds, depending on the use case. The default is a
SynchronousQueue as before.
I added:{code}
org.apache.activemq.transport.nio.SelectorManager.workQueueCapacity{code}
when > 0, it will swap out the SynchronousQueue for a capacity limited queue
with the specified workQueueCapacity
In this way, a limited pool (one that is at maximumPoolSize) can queue up some
work before getting rejected and falling back to use the calling thread.
> 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: Gary Tully
> Fix For: 5.15.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)
