You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@ambari.apache.org by Jonathan Hurley <jh...@hortonworks.com> on 2017/03/07 17:01:31 UTC
Review Request 57381: Alert Event Publisher Executor Doesn't Scale
Threads
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57381/
-----------------------------------------------------------
Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, and Robert Levas.
Bugs: AMBARI-20345
https://issues.apache.org/jira/browse/AMBARI-20345
Repository: ambari
Description
-------
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.
Diffs
-----
ambari-server/docs/configuration/index.md 968db56
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java eaecf35
ambari-server/src/main/java/org/apache/ambari/server/events/publishers/AlertEventPublisher.java 6b6f674
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/AlertResourceProviderTest.java 4b2bb7a
Diff: https://reviews.apache.org/r/57381/diff/1/
Testing
-------
PENDING
Thanks,
Jonathan Hurley
Re: Review Request 57381: Alert Event Publisher Executor Doesn't Scale
Threads
Posted by Dmitro Lisnichenko <dl...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57381/#review168164
-----------------------------------------------------------
Ship it!
Ship It!
- Dmitro Lisnichenko
On March 7, 2017, 7:57 p.m., Jonathan Hurley wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57381/
> -----------------------------------------------------------
>
> (Updated March 7, 2017, 7:57 p.m.)
>
>
> Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, and Robert Levas.
>
>
> Bugs: AMBARI-20345
> https://issues.apache.org/jira/browse/AMBARI-20345
>
>
> Repository: ambari
>
>
> Description
> -------
>
> 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.
>
>
> Diffs
> -----
>
> ambari-server/docs/configuration/index.md 968db56
> ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java 0991814
> ambari-server/src/main/java/org/apache/ambari/server/events/publishers/AlertEventPublisher.java 6b6f674
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/AlertResourceProviderTest.java 4b2bb7a
> ambari-server/src/test/java/org/apache/ambari/server/orm/dao/AlertsDAOCachedTest.java 02d942a
> ambari-server/src/test/java/org/apache/ambari/server/state/services/CachedAlertFlushServiceTest.java 0ad67d0
>
>
> Diff: https://reviews.apache.org/r/57381/diff/2/
>
>
> Testing
> -------
>
> Audit done.
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 21:42 min
> [INFO] Finished at: 2017-03-07T12:42:13-05:00
> [INFO] Final Memory: 65M/760M
> [INFO] ------------------------------------------------------------------------
>
>
> Thanks,
>
> Jonathan Hurley
>
>
Re: Review Request 57381: Alert Event Publisher Executor Doesn't Scale
Threads
Posted by Jonathan Hurley <jh...@hortonworks.com>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57381/
-----------------------------------------------------------
(Updated March 7, 2017, 12:57 p.m.)
Review request for Ambari, Dmytro Grinenko, Dmitro Lisnichenko, and Robert Levas.
Bugs: AMBARI-20345
https://issues.apache.org/jira/browse/AMBARI-20345
Repository: ambari
Description
-------
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.
Diffs (updated)
-----
ambari-server/docs/configuration/index.md 968db56
ambari-server/src/main/java/org/apache/ambari/server/configuration/Configuration.java 0991814
ambari-server/src/main/java/org/apache/ambari/server/events/publishers/AlertEventPublisher.java 6b6f674
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/AlertResourceProviderTest.java 4b2bb7a
ambari-server/src/test/java/org/apache/ambari/server/orm/dao/AlertsDAOCachedTest.java 02d942a
ambari-server/src/test/java/org/apache/ambari/server/state/services/CachedAlertFlushServiceTest.java 0ad67d0
Diff: https://reviews.apache.org/r/57381/diff/2/
Changes: https://reviews.apache.org/r/57381/diff/1-2/
Testing (updated)
-------
Audit done.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21:42 min
[INFO] Finished at: 2017-03-07T12:42:13-05:00
[INFO] Final Memory: 65M/760M
[INFO] ------------------------------------------------------------------------
Thanks,
Jonathan Hurley