>> And why we should try System.exit()? >> Why we try to stop the node before invoke Runtime#halt()?) By the same >> reasons we should try to stop the process with shutdown hooks >> invocation before Runtime#halt().
Once again: we can't be sure that node will be stopped because we don't manage code of shutdown hook. Of course we can do it using timeout. But I still don't understand the motivation of such changes. I believe that there is no real life case for proposed change. Also I described early why this change is useless for administrator and why 130 exit code is bad idea. On Tue, Jun 2, 2020 at 6:20 PM Sergey Antonov <antonovserge...@gmail.com> wrote: > > Andrey, > > > And why we should try System.exit()? > Why we try to stop the node before invoke Runtime#halt()?) By the same > reasons we should try to stop the process with shutdown hooks > invocation before Runtime#halt(). > > вт, 2 июн. 2020 г. в 17:51, Andrey Gura <ag...@apache.org>: > > > > Current implementation StopNodeOrHaltFH uses Runtime#halt(). This method > > > doesn't cause shutdown hooks. Why we don't try to stop the node by > > > System#exit() before Runtime#halt()? > > > > And why we should try System.exit()? > > > > We invoke halt() because we don't want to invoke any code in shutdown > > hook. We don't know what shut down will try to do and we can't sure > > that node will actually terminated. halt() gives such guarantee. > > > > On Tue, Jun 2, 2020 at 5:35 PM Sergey Antonov <antonovserge...@gmail.com> > > wrote: > > > > > > Andrey, Alexey, I can't agree with your position. > > > > > > Current implementation StopNodeOrHaltFH uses Runtime#halt(). This method > > > doesn't cause shutdown hooks. Why we don't try to stop the node by > > > System#exit() before Runtime#halt()? > > > > > > > > > вт, 2 июн. 2020 г. в 17:18, Andrey Gura <ag...@apache.org>: > > > > > > > Sergey, Anton, Kirill, > > > > > > > > I think we have to do not change anything in FH. At least without > > > > enough motivation. > > > > > > > > Now I see only assumption that it "could be helpful for administration > > > > purposes". It isn't enough, I believe. > > > > > > > > On Tue, Jun 2, 2020 at 4:59 PM ткаленко кирилл <tkalkir...@yandex.ru> > > > > wrote: > > > > > > > > > > Hello, Alexey! > > > > > > > > > > I didn't quite understand about merge. > > > > > > > > > > If we use StopNodeOrHaltFailureHandler with tryStop=true, then if we > > > > don't stop node by timeout, we will terminate jvm. > > > > > > > > > > Or do you suggest only stopping the node in StopNodeFailureHandler > > and > > > > terminate jvm in StopNodeOrHaltFailureHandler? or leave it as it is? > > > > > > > > > > 02.06.2020, 16:46, "Alexey Goncharuk" <alexey.goncha...@gmail.com>: > > > > > >> > How exactly do you want to change the StopNodeFH? > > > > > >> I want to stop JVM with KILL_EXIT_CODE and add an option > > (constructor > > > > > >> argument of JVM option) for disabling JVM termination. > > > > > > > > > > > > When the flag is enabled, the behavior is identical to > > StopNodeOrHaltFH > > > > > > with tryStop=false. In other words, > > > > > > StopNodeFH with enabled JVM termination === StopNodeOrHaltFH with > > > > > > tryStop=false > > > > > > StopNodeFG with disabled JVM termination ~ StopNodeOrHaltFH with > > > > > > tryStop=true > > > > > > > > > > > > Why have two different failure handlers with identical behavior? > > > > Perhaps, > > > > > > there is confusion and we should consider merging these classes > > into > > > > one? > > > > > > > > > > > > > -- > > > BR, Sergey Antonov > > > > > -- > BR, Sergey Antonov
