[
https://issues.apache.org/jira/browse/HIVE-25235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated HIVE-25235:
----------------------------------
Description:
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 best 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.
The current OOM logic in {{HiveServer2OomHookRunner}} causes HiveServer2 to
shutdown, but we already have that with the JVM shutdown hook. This JVM
shutdown hook is triggered if {{-XX:OnOutOfMemoryError="kill -9 %p"}} exists
and is the appropriate thing to do.
https://github.com/apache/hive/blob/328d197431b2ff1000fd9c56ce758013eff81ad8/service/src/java/org/apache/hive/service/server/HiveServer2.java#L443-L444
https://github.com/apache/hive/blob/cb0541a31b87016fae8e4c0e7130532c6e5f8de7/service/src/java/org/apache/hive/service/server/HiveServer2OomHookRunner.java#L42-L44
was:
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 best 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.
> 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
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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 best 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.
> The current OOM logic in {{HiveServer2OomHookRunner}} causes HiveServer2 to
> shutdown, but we already have that with the JVM shutdown hook. This JVM
> shutdown hook is triggered if {{-XX:OnOutOfMemoryError="kill -9 %p"}} exists
> and is the appropriate thing to do.
> https://github.com/apache/hive/blob/328d197431b2ff1000fd9c56ce758013eff81ad8/service/src/java/org/apache/hive/service/server/HiveServer2.java#L443-L444
> https://github.com/apache/hive/blob/cb0541a31b87016fae8e4c0e7130532c6e5f8de7/service/src/java/org/apache/hive/service/server/HiveServer2OomHookRunner.java#L42-L44
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
