[
https://issues.apache.org/jira/browse/AMQ-6396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Baik updated AMQ-6396:
----------------------------
Summary: JVM property
org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize has no effect
(post 5.14) (was: JVM property
org.apache.activemq.transport.nio.SelectorManager.maximumPoolSize has no impact)
> 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 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
