[jira] [Resolved] (AMQ-3885) ActiveMQ java client doesn't scale to thousands of queues

["Dejan Bosanac (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dejan Bosanac resolved AMQ-3885.
--------------------------------

       Resolution: Fixed
    Fix Version/s: 5.7.0

Fixed with svn revision 1363790

The client thread pool is now limited to 1000 by default and it could be further tuned with 

{code}ActiveMQConnectionFactory.setMaxThreadPoolSize(){code}

You can also provide a completely custom task runner factory using

{code}ActiveMQConnectionFactory.setSessionTaskRunner(){code}

As for the rejection policy, we decided to let it as is since it's appropriate to raise an exception when you reach your limits, so that things can be tuned further.

We also left SingleQueue and LinkedBlockingQueue is unbounded which can cause problems on its own.

Current changes should be enough to make clients scale.
                
> ActiveMQ java client doesn't scale to thousands of queues
> ---------------------------------------------------------
>
>                 Key: AMQ-3885
>                 URL: https://issues.apache.org/jira/browse/AMQ-3885
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Connector
>    Affects Versions: 5.6.0
>         Environment: core i7 laptop running win7 64bit with 8gb of ram
>            Reporter: Matan Zruya
>            Assignee: Dejan Bosanac
>              Labels: ActiveMQConnection, TaskRunnerFactory, client, java
>             Fix For: 5.7.0
>
>
> The ActiveMQ broker scales to tens of thousands of queues easily when using -Dorg.apache.activemq.UseDedicatedTaskRunner=false (false by default).
> A problem actually arises in the java client side, when a client is listening to X queues using 1 connection and Y sessions per queue, using a JMS message listener, X * Y threads will be created, when X * Y is not bounded,
> This is because each ActiveMQConnection object holds a TaskRunnerFactory which in turn has a ThreadPoolExecutor, the max pool size of the executor is defined to be Integer.MAX_VALUE, with the combination of a SynchronousQueue it creates as many threads as it pleases.
> the behavior of the executor is dependent on min pool size, core pool size, queue impl and rejection policy 
> a few options to handle this :
> 1. the default rejection policy throws an exception which is not handled,
> ThreadPoolExecutor.CallerRunsPolicy sounds better then the default
> 2. Change the queue impl to LinkedBlockingQueue and change the core pool size to a bounded value
> 3. Provide the means to supply an external executor to be shared in the app

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira