activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Baik (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-6396) JVM property org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize has no effect (post 5.14)
Date Sat, 13 Aug 2016 20:54:20 GMT

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

Jason Baik updated AMQ-6396:
----------------------------
    Description: 
http://activemq.apache.org/nio-transport-reference.html should be improved and state that
_org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize_ has no effect on the NIO
transport pool size 5.14 and beyond.

https://issues.apache.org/jira/browse/AMQ-6184 changed the work queue to an unbounded LinkedBlockingQueue,
so the size of the thread pool never grows past the core pool size as per ThreadPoolExecutor's
Javadoc:

{quote}
If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread
will be created *only if the queue is full*.
{quote}
{code}
    protected ExecutorService createDefaultExecutor() {
        ThreadPoolExecutor rc = new ThreadPoolExecutor(getDefaultCorePoolSize(), getDefaultMaximumPoolSize(),
getDefaultKeepAliveTime(), TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(),
            new ThreadFactory() {

                private long i = 0;

                @Override
                public Thread newThread(Runnable runnable) {
                    Thread t = new Thread(runnable, "ActiveMQ NIO Worker " + (i++));
                    t.setDaemon(true);
                    return t;
                }
            }, new ThreadPoolExecutor.CallerRunsPolicy());

        return rc;
    }
{code}

However, this is not true since 



I think it's better not to include in the maximumPoolSize property in the documentation since
it can confuse users into thinking that the pool size should be capped using the maximumPoolSize
property, although in reality it's the corePoolSize property that does that.

Personally this confused me greatly and wasted me a lot of time while stress-testing the MQTT
NIO connector for my company. The broker would constantly hit a live lock and spawn only 10
threads for the NIO transport, even if I set the maximumPoolSize to a larger number.

  was:
http://activemq.apache.org/nio-transport-reference.html should be improved and state that
makes it sound as if the number of threads in the SelectorManager's ThreadPoolExecutor can
be capped with the JVM property: _org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize_.

{code}
    protected ExecutorService createDefaultExecutor() {
        ThreadPoolExecutor rc = new ThreadPoolExecutor(getDefaultCorePoolSize(), getDefaultMaximumPoolSize(),
getDefaultKeepAliveTime(), TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(),
            new ThreadFactory() {

                private long i = 0;

                @Override
                public Thread newThread(Runnable runnable) {
                    Thread t = new Thread(runnable, "ActiveMQ NIO Worker " + (i++));
                    t.setDaemon(true);
                    return t;
                }
            }, new ThreadPoolExecutor.CallerRunsPolicy());

        return rc;
    }
{code}

However, this is not true since an unbounded LinkedBlockingQueue is being used with the the
executor. The size of the thread pool will never grow past the core pool size as per ThreadPoolExecutor's
Javadoc:

{quote}
If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread
will be created *only if the queue is full*.
{quote}

I think it's better not to include in the maximumPoolSize property in the documentation since
it can confuse users into thinking that the pool size should be capped using the maximumPoolSize
property, although in reality it's the corePoolSize property that does that.

Personally this confused me greatly and wasted me a lot of time while stress-testing the MQTT
NIO connector for my company. The broker would constantly hit a live lock and spawn only 10
threads for the NIO transport, even if I set the maximumPoolSize to a larger number.


> JVM property org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize has no
effect (post 5.14)
> --------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-6396
>                 URL: https://issues.apache.org/jira/browse/AMQ-6396
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Transport
>    Affects Versions: 5.14.0
>            Reporter: Jason Baik
>            Priority: Minor
>
> http://activemq.apache.org/nio-transport-reference.html should be improved and state
that _org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize_ has no effect on
the NIO transport pool size 5.14 and beyond.
> https://issues.apache.org/jira/browse/AMQ-6184 changed the work queue to an unbounded
LinkedBlockingQueue, so the size of the thread pool never grows past the core pool size as
per ThreadPoolExecutor's Javadoc:
> {quote}
> If there are more than corePoolSize but less than maximumPoolSize threads running, a
new thread will be created *only if the queue is full*.
> {quote}
> {code}
>     protected ExecutorService createDefaultExecutor() {
>         ThreadPoolExecutor rc = new ThreadPoolExecutor(getDefaultCorePoolSize(), getDefaultMaximumPoolSize(),
getDefaultKeepAliveTime(), TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(),
>             new ThreadFactory() {
>                 private long i = 0;
>                 @Override
>                 public Thread newThread(Runnable runnable) {
>                     Thread t = new Thread(runnable, "ActiveMQ NIO Worker " + (i++));
>                     t.setDaemon(true);
>                     return t;
>                 }
>             }, new ThreadPoolExecutor.CallerRunsPolicy());
>         return rc;
>     }
> {code}
> However, this is not true since 
> I think it's better not to include in the maximumPoolSize property in the documentation
since it can confuse users into thinking that the pool size should be capped using the maximumPoolSize
property, although in reality it's the corePoolSize property that does that.
> Personally this confused me greatly and wasted me a lot of time while stress-testing
the MQTT NIO connector for my company. The broker would constantly hit a live lock and spawn
only 10 threads for the NIO transport, even if I set the maximumPoolSize to a larger number.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message