[
https://issues.apache.org/jira/browse/GEODE-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-7369:
--------------------------------
Description:
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
was:
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.
[1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> 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
>
> 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)
