activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Huang (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AMQ-5480) Provider fine-grained control for SelectorManager's threadpool
Date Fri, 12 Dec 2014 06:41:13 GMT

    [ 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)

Mime
View raw message