Hi Srimanth, I recently noticed this behavior too. I filed an external JIRA with a prototype to address this issue. https://issues.apache.org/jira/browse/AMBARI-14671
Regards Jayush On 1/14/16, 10:01 AM, "Srimanth Gunturi" <[email protected]> wrote: >Hello, >Wanted to write this down and have discussion about >'java.util.concurrent.ThreadPoolExecutor' being used incorrectly in >Ambari. > >Almost all usages call the below constructor: > >public ThreadPoolExecutor( > int corePoolSize, > int maximumPoolSize, > long keepAliveTime, > TimeUnit unit, > BlockingQueue<Runnable> workQueue) > >Where typical values used are: > >new ThreadPoolExecutor( > 20, > 100, > 30000L, > TimeUnit.MILLISECONDS, > new LinkedBlockingQueue<Runnable>()) // Unbounded queue > >The weird thing about 'ThreadPoolExecutor' is that the number of threads >increases from the 'corePoolSize' (20) to the 'maximumPoolSize' (100) >ONLY when the BlockingQueue is full. Whenever we use an unbounded >blocking queue, the number of threads never goes past the 'corePoolSize'. > >The javadoc states: "If there are more than corePoolSize but less than >maximumPoolSize threads running, a new thread will be created only if the >queue is full" > >So our thinking that the Executor will automatically increase the number >of threads upto 'maximumPoolSize' and store overflowing requests into the >queue (unbounded) is incorrect. Due to our usage, the number of threads >never increases beyond 'corePoolSize'. > >I do not understand the reason why it is implemented this way, but we run >into performance issues by getting stuck with 'corePoolSize' thread >count. I am looking into a fix for using ThreadPoolExecutor where the >number of threads increases upto 'maximumPoolSize'. > >Regards, >Srimanth? >
