[
https://issues.apache.org/jira/browse/GEODE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16963485#comment-16963485
]
Bill Burcham commented on GEODE-7369:
-------------------------------------
[~dschneider] had a good comment on the PR:
"I approve of this being deprecated and removed from our external apis in the
future. Looking at the public methods on this class I don't really see any that
a geode user would want to invoke. I do think we should consider if this class
is helpful for geode. I believe it will cause geode servers to attempt a
shutdown if they see a critical exception. In the past we had servers that had
these critical exception and yet kept running (since only the thread that had
the exception was terminated) with a JVM state that could no longer be trusted.
By trying to get the JVM to terminate we at least have a chance of members that
have such exception leaving the distributed system and restart logic can then
kick in. But it might make more sense for some external monitor (that you can
trust) to be responsible for restarting these sick JVMs instead of trying to do
it internally in the sick JVM."
> Deprecate SystemFailure Class
> -----------------------------
>
> Key: GEODE-7369
> URL: https://issues.apache.org/jira/browse/GEODE-7369
> Project: Geode
> Issue Type: Bug
> Components: core
> Reporter: Bill Burcham
> Assignee: Bill Burcham
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{SystemFailure}} class is a clearing house for detecting and attempting
> to mitigate {{SystemFailure}} exceptions e.g. {{VirtualMachineError}} and
> {{OutOfMemoryError}}.
> This class should not exist. {{SystemFailure}} exceptions should be allowed
> to percolate up and cause the JVM to terminate as soon as possible with an
> informative message in the log, if possible.
> Here is what the JVM spec has to say [1]:
> "A Java Virtual Machine implementation throws an object that is an instance
> of a subclass of the class VirtualMethodError (sic) when an internal error or
> resource limitation prevents it from implementing the semantics described in
> this chapter. This specification cannot predict where internal errors or
> resource limitations may be encountered and does not mandate precisely when
> they can be reported."
> There's a typo in the spec there: it says "VirtualMethodError" when it means
> "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not apply
> after you've encountered a {{VirtualMachineError}}. As a result, there is no
> reason to believe that subsequent processing will make things _better_ (than
> exiting immediately).
> The SystemFailure class should be deprecated so no new dependencies to it are
> added. Existing dependencies on it, should be eliminated over time.
> This ticket was discussed on the Apache Geode dev list and "rough consensus"
> was achieved[2]
> [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> [2]
> https://lists.apache.org/thread.html/61a1fbeda2c29f83e695f9e20512c15ab6db8a4c91990352a41f7dfb@%3Cdev.geode.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
