You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "David Mollitor (Jira)" <ji...@apache.org> on 2021/06/10 15:52:00 UTC

[jira] [Assigned] (HIVE-25235) Remove ThreadPoolExecutorWithOomHook

     [ https://issues.apache.org/jira/browse/HIVE-25235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Mollitor reassigned HIVE-25235:
-------------------------------------


> Remove ThreadPoolExecutorWithOomHook
> ------------------------------------
>
>                 Key: HIVE-25235
>                 URL: https://issues.apache.org/jira/browse/HIVE-25235
>             Project: Hive
>          Issue Type: Improvement
>          Components: HiveServer2
>            Reporter: David Mollitor
>            Assignee: David Mollitor
>            Priority: Major
>
> While I was looking at [HIVE-24846] to better perform OOM logging and I just realized that this is not a good way to handle OOM.
> https://stackoverflow.com/questions/1692230/is-it-possible-to-catch-out-of-memory-exception-in-java
> bq. there's likely no easy way for you to recover from it if you do catch it
> If we want to handle OOM, it's best to do it from outside. It's be to do it with the JVM facilities:
> {{-XX:+ExitOnOutOfMemoryError}}
> {{-XX:OnOutOfMemoryError}}
> It seems odd that the OOM handler attempts to load a handler and then do more work when clearly the server is hosed at this point and just requesting to do more work will further add to memory pressure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)