[
https://issues.apache.org/jira/browse/AMBARI-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayush Luniya updated AMBARI-14671:
-----------------------------------
Fix Version/s: (was: 2.5.0)
3.0.0
> Reevaluate the use of threadpools in Ambari code base
> -----------------------------------------------------
>
> Key: AMBARI-14671
> URL: https://issues.apache.org/jira/browse/AMBARI-14671
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.2.0
> Reporter: Jayush Luniya
> Assignee: Jayush Luniya
> Fix For: 3.0.0
>
> Attachments: DynamicScaling.tgz
>
>
> As part of investigation for BUG-43981, noticed that in many places in the
> Ambari code base, the way we use the threadpool is not quite correct. We
> will never scale up the number of threads on high load when we use unbounded
> queues. This could lead to performance bottlenecks especially if we are
> configure ThreadPoolExecutor with corePoolSize=0 and maxPoolSize=10, only one
> thread will ever be spawned. See observations below
> Observations:
> 1. When a ThreadPoolExecutor object is created, the pool size is 0 (i.e. no
> new threads are created then) unless prestartAllCoreThreads() is called. Also
> if we set allowCoreThreadTimeOut(true), idle core threads will also be
> reclaimed.
> 2. In our code base, I observed that we create a threadpool using unlimited
> queue. However the pool will never scale up from coreThreads -> maxThreads as
> the request will always get queued.
> {code:java}
> LinkedBlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>(); //
> unlimited Queue
> ThreadPoolExecutor threadPoolExecutor =
> new ThreadPoolExecutor(
> THREAD_POOL_CORE_SIZE,
> THREAD_POOL_MAX_SIZE,
> THREAD_POOL_TIMEOUT_MILLIS,
> TimeUnit.MILLISECONDS,
> queue);
> {code}
> http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html
> {quote}
> Unbounded queues. Using an unbounded queue (for example a LinkedBlockingQueue
> without a predefined capacity) will cause new tasks to wait in the queue when
> all corePoolSize threads are busy. Thus, no more than corePoolSize threads
> will ever be created. (And the value of the maximumPoolSize therefore doesn't
> have any effect.) This may be appropriate when each task is completely
> independent of others, so tasks cannot affect each others execution; for
> example, in a web page server. While this style of queuing can be useful in
> smoothing out transient bursts of requests, it admits the possibility of
> unbounded work queue growth when commands continue to arrive on average
> faster than they can be processed.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
