You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Benjamin Huang (JIRA)" <ji...@apache.org> on 2014/12/12 07:39:14 UTC
[jira] [Comment Edited] (AMQ-5480) Provider fine-grained control
for SelectorManager's threadpool
[ 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:38 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 adjust 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)