[
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}
Leaving the documentation as is 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 5.14 and beyond.
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 _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.
> 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}
> Leaving the documentation as is 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 5.14 and beyond.
> 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)
