ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-20345) Alert Event Publisher Executor Doesn't Scale Threads
Date Wed, 08 Mar 2017 13:41:38 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-20345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901263#comment-15901263
] 

Hudson commented on AMBARI-20345:
---------------------------------

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #6974 (See [https://builds.apache.org/job/Ambari-trunk-Commit/6974/])
AMBARI-20345 - Alert Event Publisher Executor Doesn't Scale Threads (jhurley: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=ece0736c095d98c97e4cde7d5384af3d46a921dd])
* (edit) ambari-server/src/test/java/org/apache/ambari/server/orm/dao/AlertsDAOCachedTest.java


> Alert Event Publisher Executor Doesn't Scale Threads
> ----------------------------------------------------
>
>                 Key: AMBARI-20345
>                 URL: https://issues.apache.org/jira/browse/AMBARI-20345
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.5.0
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>             Fix For: 2.5.0
>
>         Attachments: AMBARI-20345.patch
>
>
> The event bus which is used to handling incoming {{AlertEvent}} events is incorrectly
initialized and can never scale from the core number of threads. This is because it uses an
unbounded queued. From the [ThreadPoolExecutor|https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html]
documentation:
> {quote}
> A ThreadPoolExecutor will automatically adjust the pool size (see getPoolSize()) according
to the bounds set by corePoolSize (see getCorePoolSize()) and maximumPoolSize (see getMaximumPoolSize()).
When a new task is submitted in method execute(java.lang.Runnable), and fewer than corePoolSize
threads are running, a new thread is created to handle the request, even if other worker threads
are idle. 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}
> We should switch to a configurable, bounded queue so that this property can be utilized
in large clusters where more than the default of 2 core threads is needed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message