[jira] [Resolved] (AMQ-6184) Improve nio transport scalability

["Gary Tully (JIRA)" <ji...@apache.org>]

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