You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Bill Burcham <bi...@gmail.com> on 2019/10/28 19:01:15 UTC
Deprecate SystemFailure Class
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.
Do you have any objections to deprecating the class and beginning
elimination of usage of it within Geode?
Regards,
Bill
[1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
[2] oh and here's a ticket https://issues.apache.org/jira/browse/GEODE-7369
Re: Deprecate SystemFailure Class
Posted by Joris Melchior <jm...@pivotal.io>.
+1.
On Mon, Oct 28, 2019 at 4:22 PM Robert Houghton <rh...@pivotal.io>
wrote:
> +1.
>
> On Mon, Oct 28, 2019 at 12:11 PM Bill Burcham <bi...@gmail.com>
> wrote:
>
> > 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.
> >
> > Do you have any objections to deprecating the class and beginning
> > elimination of usage of it within Geode?
> >
> > Regards,
> > Bill
> >
> > [1]
> > https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> > [2] oh and here's a ticket
> > https://issues.apache.org/jira/browse/GEODE-7369
> >
>
--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427
“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>
Re: Deprecate SystemFailure Class
Posted by Robert Houghton <rh...@pivotal.io>.
+1.
On Mon, Oct 28, 2019 at 12:11 PM Bill Burcham <bi...@gmail.com>
wrote:
> 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.
>
> Do you have any objections to deprecating the class and beginning
> elimination of usage of it within Geode?
>
> Regards,
> Bill
>
> [1]
> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> [2] oh and here's a ticket
> https://issues.apache.org/jira/browse/GEODE-7369
>
Re: Deprecate SystemFailure Class
Posted by Bill Burcham <bi...@gmail.com>.
Hearing no objections or concerns, I will begin the deprecation process[1]
for SystemFailure.
After that I'll remove the dependencies [2] on SystemFailure in the
membership subsystem.
[1] https://issues.apache.org/jira/browse/GEODE-7369
[2] https://issues.apache.org/jira/browse/GEODE-7354
Re: Deprecate SystemFailure Class
Posted by Bill Burcham <bi...@gmail.com>.
The SystemFailure class is in the org.apache.geode package which means it
is part of the public API.
My purpose in messaging the dev list was to discover any concerns or
objections to adding the deprecated flag to SystemFailure per GEODE-7369.
Related to that work, I intend to eliminate calls to SystemFailure methods
e.g. initiateFailure() from within the membership subsystem per
https://issues.apache.org/jira/browse/GEODE-7354
It's my opinion we should eventually eliminate all such calls throughout
Geode eventually, but I don't know of any imminent plan to do so.
On Tue, Oct 29, 2019 at 8:26 AM Bruce Schuchardt <bs...@pivotal.io>
wrote:
> Bill, are you proposing to remove calls to
> SystemFailure.initiateFailure() and remove all of the emergency-class
> stuff or just add a Deprecated flag to SystemFailure?
>
>
> On 10/28/19 12:01 PM, Bill Burcham wrote:
> > 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.
> >
> > Do you have any objections to deprecating the class and beginning
> > elimination of usage of it within Geode?
> >
> > Regards,
> > Bill
> >
> > [1]
> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> > [2] oh and here's a ticket
> https://issues.apache.org/jira/browse/GEODE-7369
> >
>
Re: Deprecate SystemFailure Class
Posted by Bruce Schuchardt <bs...@pivotal.io>.
Bill, are you proposing to remove calls to
SystemFailure.initiateFailure() and remove all of the emergency-class
stuff or just add a Deprecated flag to SystemFailure?
On 10/28/19 12:01 PM, Bill Burcham wrote:
> 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.
>
> Do you have any objections to deprecating the class and beginning
> elimination of usage of it within Geode?
>
> Regards,
> Bill
>
> [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> [2] oh and here's a ticket https://issues.apache.org/jira/browse/GEODE-7369
>