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

Xuefu Zhang edited comment on HIVE-17586 at 9/27/17 3:06 AM:
-------------------------------------------------------------

Actually no according to java doc at 
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html:

{quote}
If the pool currently has more than corePoolSize threads, excess threads will 
be terminated if they have been idle for more than the keepAliveTime (see 
getKeepAliveTime(java.util.concurrent.TimeUnit)).
{quote}
 
Because we use fixed pool size, there are no "excess threads" to idle out.


was (Author: xuefuz):
Actually no according java doc at 
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadPoolExecutor.html:

{quote}
If the pool currently has more than corePoolSize threads, excess threads will 
be terminated if they have been idle for more than the keepAliveTime (see 
getKeepAliveTime(java.util.concurrent.TimeUnit)).
{quote}
 
Because we use fixed pool size, there are no "excess threads" to idle out.

> Make HS2 BackgroundOperationPool not fixed
> ------------------------------------------
>
>                 Key: HIVE-17586
>                 URL: https://issues.apache.org/jira/browse/HIVE-17586
>             Project: Hive
>          Issue Type: Bug
>          Components: HiveServer2
>    Affects Versions: 1.1.0
>            Reporter: Xuefu Zhang
>            Assignee: Xuefu Zhang
>         Attachments: HIVE-17586.1.patch, HIVE-17586.patch
>
>
> Currently the threadpool for background asynchronous operatons has a fixed 
> size controled by {{hive.server2.async.exec.threads}}. However, the thread 
> factory supplied for this threadpool is {{ThreadFactoryWithGarbageCleanup}} 
> which creates ThreadWithGarbageCleanup. Since this is a fixed threadpool, the 
> thread is actually never killed, defecting the purpose of garbage cleanup as 
> noted in the thread class name. On the other hand, since these threads never 
> go away, significant resources such as threadlocal variables (classloaders, 
> hiveconfs, etc) are holding up even if there is no operation running. This 
> can lead to escalated HS2 memory usage.
> Ideally, the threadpool should not be fixed, allowing thread to die out so 
> resources can be reclaimed. The existing config 
> {{hive.server2.async.exec.threads}} is treated as the max, and we can add a 
> min for the threadpool {{hive.server2.async.exec.min.threads}}. Default value 
> for this configure is -1, which keeps the existing behavior.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to