[
https://issues.apache.org/jira/browse/AMQ-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14243782#comment-14243782
]
Benjamin Huang edited comment on AMQ-5480 at 12/12/14 6:40 AM:
----------------------------------------------------------------
Timothy, I've verified above options in 5.11-20141209.032416-170 and found them
work as expected. However, here're some tuning options which are also helpful
in adjusting the threadpool's behavior. You can find them
[here|https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html],
as highlighted below:
{quote}
Rejected tasks
New tasks submitted in method execute(java.lang.Runnable) will be rejected when
the Executor has been shut down, and also when the Executor uses finite bounds
for both maximum threads and work queue capacity, and is saturated. In either
case, the execute method invokes the
RejectedExecutionHandler.rejectedExecution(java.lang.Runnable,
java.util.concurrent.ThreadPoolExecutor) method of its
RejectedExecutionHandler. Four predefined handler policies are provided:
In the default ThreadPoolExecutor.*AbortPolicy*, the handler throws a runtime
RejectedExecutionException upon rejection.
In ThreadPoolExecutor.*CallerRunsPolicy*, the thread that invokes execute
itself runs the task. This provides a simple feedback control mechanism that
will slow down the rate that new tasks are submitted.
In ThreadPoolExecutor.*DiscardPolicy*, a task that cannot be executed is simply
dropped.
In ThreadPoolExecutor.*DiscardOldestPolicy*, if the executor is not shut down,
the task at the head of the work queue is dropped, and then execution is
retried (which can fail again, causing this to be repeated.)
It is possible to define and use other kinds of RejectedExecutionHandler
classes. Doing so requires some care especially when policies are designed to
work only under particular capacity or queuing policies.
{quote}
It'll be appreciated if you can also implement them in the SelectorManager
class. I'm not sure it's appropriate reopen this topic for this, if it's not, I
can open another issue for this.
was (Author: benjaminhuang):
Timothy, I've verified above options in 5.11-20141209.032416-170 and found them
work as expected. However, here're some tuning options which are also helpful
in adjusting the threadpool's behavior. You can find them
[here|https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html],
as highlighted below:
{quote}
Rejected tasks
New tasks submitted in method execute(java.lang.Runnable) will be rejected when
the Executor has been shut down, and also when the Executor uses finite bounds
for both maximum threads and work queue capacity, and is saturated. In either
case, the execute method invokes the
RejectedExecutionHandler.rejectedExecution(java.lang.Runnable,
java.util.concurrent.ThreadPoolExecutor) method of its
RejectedExecutionHandler. Four predefined handler policies are provided:
In the default ThreadPoolExecutor.AbortPolicy, the handler throws a runtime
RejectedExecutionException upon rejection.
In ThreadPoolExecutor.CallerRunsPolicy, the thread that invokes execute itself
runs the task. This provides a simple feedback control mechanism that will slow
down the rate that new tasks are submitted.
In ThreadPoolExecutor.*DiscardPolicy*, a task that cannot be executed is simply
dropped.
In ThreadPoolExecutor.DiscardOldestPolicy, if the executor is not shut down,
the task at the head of the work queue is dropped, and then execution is
retried (which can fail again, causing this to be repeated.)
It is possible to define and use other kinds of RejectedExecutionHandler
classes. Doing so requires some care especially when policies are designed to
work only under particular capacity or queuing policies.
{quote}
It'll be appreciated if you can also implement them in the SelectorManager
class. I'm not sure it's appropriate reopen this topic for this, if it's not, I
can open another issue for this.
> Provider fine-grained control for SelectorManager's threadpool
> --------------------------------------------------------------
>
> Key: AMQ-5480
> URL: https://issues.apache.org/jira/browse/AMQ-5480
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Selector
> Affects Versions: 5.9.0
> Environment: UbuntuServer 12.04 x86_64, ActiveMQ-5,9.1, E5-2620 v2
> @2.10GHz, 64GB RAM
> Reporter: Benjamin Huang
> Assignee: Timothy Bish
> Priority: Minor
> Fix For: 5.11.0
>
>
> In SelectorManager::createDefaultExecutor, the ThreadPoolExecutor is created
> with Integer.MAX_VALUE as MaximumPoolSize. This does not work well under our
> scenarios. It would be nicer to give fine-control over CorePoolSize,
> MaximumPoolSize as what's been done for KeepAlive Time
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
