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

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

David Mollitor created HIVE-25235:
-------------------------------------

             Summary: 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


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)