[DISCUSS] Ignite process exit code on node stop by failure handler
Locked
[DISCUSS] Ignite process exit code on node stop by failure handler
 
|
Hello, Igniters!
I'd like to discuss behaviour of Ignite process exit code if the node was stopped by failure handler [1][2]. At the moment ignite process returns exit code 0 after the stop in all scenarios, except runtime halt by StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] My proposal: always finish Ignite process with code [3], if a node was stopped by FH. It could be helpful for administration purposes, you can distinguish normal node stop from node stop by FH on OS level. WDYT? [1] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html [2] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html [3] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE -- BR, Sergey Antonov |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
I've created the Ignite ticket for this improvement [1].
[1] https://issues.apache.org/jira/browse/IGNITE-13047 чт, 21 мая 2020 г. в 00:46, Sergey Antonov <[hidden email]>: > Hello, Igniters! > > I'd like to discuss behaviour of Ignite process exit code if the node was > stopped by failure handler [1][2]. At the moment ignite process returns > exit code 0 after the stop in all scenarios, except runtime halt by > StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] > > My proposal: always finish Ignite process with code [3], if a node was > stopped by FH. It could be helpful for administration purposes, you can > distinguish normal node stop from node stop by FH on OS level. > > WDYT? > > [1] > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > > [2] > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > > [3] > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > -- > BR, Sergey Antonov > -- BR, Sergey Antonov |
Re[2]: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
Thank you Sergey, as for me — very useful proposal huge +1 here. >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov <[hidden email]>: > >I've created the Ignite ticket for this improvement [1]. > >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < [hidden email] >: > >> Hello, Igniters! >> >> I'd like to discuss behaviour of Ignite process exit code if the node was >> stopped by failure handler [1][2]. At the moment ignite process returns >> exit code 0 after the stop in all scenarios, except runtime halt by >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] >> >> My proposal: always finish Ignite process with code [3], if a node was >> stopped by FH. It could be helpful for administration purposes, you can >> distinguish normal node stop from node stop by FH on OS level. >> >> WDYT? >> >> [1] >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html >> >> [2] >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html >> >> [3] >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE >> -- >> BR, Sergey Antonov >> > >-- >BR, Sergey Antonov > |
Re: Re[2]: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
It seems reasonable to me. Also I would like to propose adding value of
Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. Dev ops/admins/anyone who admins Ignite may want to know it's value without going to Java code. чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky <[hidden email]>: > > Thank you Sergey, as for me — very useful proposal huge +1 here. > > > >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > [hidden email]>: > > > >I've created the Ignite ticket for this improvement [1]. > > > >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > > > >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < [hidden email] >: > > > >> Hello, Igniters! > >> > >> I'd like to discuss behaviour of Ignite process exit code if the node > was > >> stopped by failure handler [1][2]. At the moment ignite process returns > >> exit code 0 after the stop in all scenarios, except runtime halt by > >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] > >> > >> My proposal: always finish Ignite process with code [3], if a node was > >> stopped by FH. It could be helpful for administration purposes, you can > >> distinguish normal node stop from node stop by FH on OS level. > >> > >> WDYT? > >> > >> [1] > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > >> > >> [2] > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > >> > >> [3] > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > >> -- > >> BR, Sergey Antonov > >> > > > >-- > >BR, Sergey Antonov > > > > > > |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
I think that [1] and [2] should not be changed, because we can kill another client code in this jvm.
I suggest for these purposes to create a new [3] which will be like [1] but with a call [4] after node stop. Objections or comments? [1] - org.apache.ignite.failure.StopNodeFailureHandler [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler [3] - org.apache.ignite.failure.FailureHandler [4] - java.lang.System#exit 25.05.2020, 22:09, "Dmitriy Pavlov" <[hidden email]>: > It seems reasonable to me. Also I would like to propose adding value of > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > Dev ops/admins/anyone who admins Ignite may want to know it's value without > going to Java code. > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky <[hidden email]>: > >> Thank you Sergey, as for me — very useful proposal huge +1 here. >> >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < >> [hidden email]>: >> > >> >I've created the Ignite ticket for this improvement [1]. >> > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 >> > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < [hidden email] >: >> > >> >> Hello, Igniters! >> >> >> >> I'd like to discuss behaviour of Ignite process exit code if the node >> was >> >> stopped by failure handler [1][2]. At the moment ignite process returns >> >> exit code 0 after the stop in all scenarios, except runtime halt by >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] >> >> >> >> My proposal: always finish Ignite process with code [3], if a node was >> >> stopped by FH. It could be helpful for administration purposes, you can >> >> distinguish normal node stop from node stop by FH on OS level. >> >> >> >> WDYT? >> >> >> >> [1] >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html >> >> >> >> [2] >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html >> >> >> >> [3] >> >> >> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE >> >> -- >> >> BR, Sergey Antonov >> >> >> > >> >-- >> >BR, Sergey Antonov >> > |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
Hello, Kirill!
I'd prefer to don't create a new implementation of a failure handler. We already have 4 different failure handlers. We will have 6 FH (StopNodeFH with exit code, StopNodeOrHaltFH with exit code), if we go your way. It won't make our product simpler and easier. I think, we must notify a user if the cluster node had been stopped by a failure handler. We can't achieve this goal without changing current FH behavior. So I propose to change it and stop the process with KILL_EXIT_CODE. But it would be nice if users will have a flag for avoiding process stop after a node failure. We can introduce a new JVM option or FH parameter for that reason. Of course, we must highlight this change in the release notes. пн, 1 июн. 2020 г. в 19:07, ткаленко кирилл <[hidden email]>: > I think that [1] and [2] should not be changed, because we can kill > another client code in this jvm. > I suggest for these purposes to create a new [3] which will be like [1] > but with a call [4] after node stop. > Objections or comments? > > [1] - org.apache.ignite.failure.StopNodeFailureHandler > [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler > [3] - org.apache.ignite.failure.FailureHandler > [4] - java.lang.System#exit > > 25.05.2020, 22:09, "Dmitriy Pavlov" <[hidden email]>: > > It seems reasonable to me. Also I would like to propose adding value of > > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > > > Dev ops/admins/anyone who admins Ignite may want to know it's value > without > > going to Java code. > > > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky > <[hidden email]>: > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > >> > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > >> [hidden email]>: > >> > > >> >I've created the Ignite ticket for this improvement [1]. > >> > > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > >> > > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < > [hidden email] >: > >> > > >> >> Hello, Igniters! > >> >> > >> >> I'd like to discuss behaviour of Ignite process exit code if the > node > >> was > >> >> stopped by failure handler [1][2]. At the moment ignite process > returns > >> >> exit code 0 after the stop in all scenarios, except runtime halt by > >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] > >> >> > >> >> My proposal: always finish Ignite process with code [3], if a node > was > >> >> stopped by FH. It could be helpful for administration purposes, you > can > >> >> distinguish normal node stop from node stop by FH on OS level. > >> >> > >> >> WDYT? > >> >> > >> >> [1] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > >> >> > >> >> [2] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > >> >> > >> >> [3] > >> >> > >> > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > >> >> -- > >> >> BR, Sergey Antonov > >> >> > >> > > >> >-- > >> >BR, Sergey Antonov > >> > > -- BR, Sergey Antonov |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
Sergey,
How exactly do you want to change the StopNodeFH? The current behavior does not terminate the JVM and its exit code is totally out of our control; one of the use-cases we had in mind for this failure handler is that a user may have other processes running in the same JVM, so we do not want Ignite to affect them. For me, the exit code makes sense only for StopNodeOrHaltFH with tryStop=false (otherwise, the JVM exit is not guaranteed as well), but we already use the KILL_EXIT_CODE there. пн, 1 июн. 2020 г. в 23:19, Sergey Antonov <[hidden email]>: > Hello, Kirill! > > I'd prefer to don't create a new implementation of a failure handler. We > already have 4 different failure handlers. We will have 6 FH (StopNodeFH > with exit code, StopNodeOrHaltFH with exit code), if we go your way. It > won't make our product simpler and easier. > > I think, we must notify a user if the cluster node had been stopped by a > failure handler. We can't achieve this goal without changing current FH > behavior. So I propose to change it and stop the process with > KILL_EXIT_CODE. > But it would be nice if users will have a flag for avoiding process stop > after a node failure. We can introduce a new JVM option or FH parameter for > that reason. Of course, we must highlight this change in the release notes. > > пн, 1 июн. 2020 г. в 19:07, ткаленко кирилл <[hidden email]>: > > > I think that [1] and [2] should not be changed, because we can kill > > another client code in this jvm. > > I suggest for these purposes to create a new [3] which will be like [1] > > but with a call [4] after node stop. > > Objections or comments? > > > > [1] - org.apache.ignite.failure.StopNodeFailureHandler > > [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler > > [3] - org.apache.ignite.failure.FailureHandler > > [4] - java.lang.System#exit > > > > 25.05.2020, 22:09, "Dmitriy Pavlov" <[hidden email]>: > > > It seems reasonable to me. Also I would like to propose adding value of > > > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > > > > > Dev ops/admins/anyone who admins Ignite may want to know it's value > > without > > > going to Java code. > > > > > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky > > <[hidden email]>: > > > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > > >> > > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > > >> [hidden email]>: > > >> > > > >> >I've created the Ignite ticket for this improvement [1]. > > >> > > > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > > >> > > > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < > > [hidden email] >: > > >> > > > >> >> Hello, Igniters! > > >> >> > > >> >> I'd like to discuss behaviour of Ignite process exit code if the > > node > > >> was > > >> >> stopped by failure handler [1][2]. At the moment ignite process > > returns > > >> >> exit code 0 after the stop in all scenarios, except runtime halt > by > > >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 [3] > > >> >> > > >> >> My proposal: always finish Ignite process with code [3], if a node > > was > > >> >> stopped by FH. It could be helpful for administration purposes, > you > > can > > >> >> distinguish normal node stop from node stop by FH on OS level. > > >> >> > > >> >> WDYT? > > >> >> > > >> >> [1] > > >> >> > > >> > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > > >> >> > > >> >> [2] > > >> >> > > >> > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > > >> >> > > >> >> [3] > > >> >> > > >> > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > > >> >> -- > > >> >> BR, Sergey Antonov > > >> >> > > >> > > > >> >-- > > >> >BR, Sergey Antonov > > >> > > > > > > -- > BR, Sergey Antonov > |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
Alexey,
> 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. вт, 2 июн. 2020 г. в 12:54, Alexey Goncharuk <[hidden email]>: > Sergey, > > How exactly do you want to change the StopNodeFH? The current behavior does > not terminate the JVM and its exit code is totally out of our control; one > of the use-cases we had in mind for this failure handler is that a user may > have other processes running in the same JVM, so we do not want Ignite to > affect them. > > For me, the exit code makes sense only for StopNodeOrHaltFH with > tryStop=false (otherwise, the JVM exit is not guaranteed as well), but we > already use the KILL_EXIT_CODE there. > > пн, 1 июн. 2020 г. в 23:19, Sergey Antonov <[hidden email]>: > > > Hello, Kirill! > > > > I'd prefer to don't create a new implementation of a failure handler. We > > already have 4 different failure handlers. We will have 6 FH (StopNodeFH > > with exit code, StopNodeOrHaltFH with exit code), if we go your way. It > > won't make our product simpler and easier. > > > > I think, we must notify a user if the cluster node had been stopped by a > > failure handler. We can't achieve this goal without changing current FH > > behavior. So I propose to change it and stop the process with > > KILL_EXIT_CODE. > > But it would be nice if users will have a flag for avoiding process stop > > after a node failure. We can introduce a new JVM option or FH parameter > for > > that reason. Of course, we must highlight this change in the release > notes. > > > > пн, 1 июн. 2020 г. в 19:07, ткаленко кирилл <[hidden email]>: > > > > > I think that [1] and [2] should not be changed, because we can kill > > > another client code in this jvm. > > > I suggest for these purposes to create a new [3] which will be like [1] > > > but with a call [4] after node stop. > > > Objections or comments? > > > > > > [1] - org.apache.ignite.failure.StopNodeFailureHandler > > > [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler > > > [3] - org.apache.ignite.failure.FailureHandler > > > [4] - java.lang.System#exit > > > > > > 25.05.2020, 22:09, "Dmitriy Pavlov" <[hidden email]>: > > > > It seems reasonable to me. Also I would like to propose adding value > of > > > > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > > > > > > > Dev ops/admins/anyone who admins Ignite may want to know it's value > > > without > > > > going to Java code. > > > > > > > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky > > > <[hidden email]>: > > > > > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > > > >> > > > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > > > >> [hidden email]>: > > > >> > > > > >> >I've created the Ignite ticket for this improvement [1]. > > > >> > > > > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > > > >> > > > > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < > > > [hidden email] >: > > > >> > > > > >> >> Hello, Igniters! > > > >> >> > > > >> >> I'd like to discuss behaviour of Ignite process exit code if the > > > node > > > >> was > > > >> >> stopped by failure handler [1][2]. At the moment ignite process > > > returns > > > >> >> exit code 0 after the stop in all scenarios, except runtime halt > > by > > > >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 > [3] > > > >> >> > > > >> >> My proposal: always finish Ignite process with code [3], if a > node > > > was > > > >> >> stopped by FH. It could be helpful for administration purposes, > > you > > > can > > > >> >> distinguish normal node stop from node stop by FH on OS level. > > > >> >> > > > >> >> WDYT? > > > >> >> > > > >> >> [1] > > > >> >> > > > >> > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > > > >> >> > > > >> >> [2] > > > >> >> > > > >> > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > > > >> >> > > > >> >> [3] > > > >> >> > > > >> > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > > > >> >> -- > > > >> >> BR, Sergey Antonov > > > >> >> > > > >> > > > > >> >-- > > > >> >BR, Sergey Antonov > > > >> > > > > > > > > > > -- > > BR, Sergey Antonov > > > -- BR, Sergey Antonov |
|
|
Definitely agree with Alexey Goncharuk. Mentioned FH implementations
don't terminate JVM. I think returning KILL_EXIT_CODE is bad idea because actually process wasn't terminated using SIGINT. So it contradicts to motivation described in proposal. Also how could it help to administrators. For example node was stopped by FH. What could script to do? Restart node? It is not good idea because node was intentionally configured to be stopped. Sent some notification? It could be done by monitoring tools. I don't understand the motivation. On Tue, Jun 2, 2020 at 1:53 PM Sergey Antonov <[hidden email]> wrote: > > Alexey, > > > 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. > > вт, 2 июн. 2020 г. в 12:54, Alexey Goncharuk <[hidden email]>: > > > Sergey, > > > > How exactly do you want to change the StopNodeFH? The current behavior does > > not terminate the JVM and its exit code is totally out of our control; one > > of the use-cases we had in mind for this failure handler is that a user may > > have other processes running in the same JVM, so we do not want Ignite to > > affect them. > > > > For me, the exit code makes sense only for StopNodeOrHaltFH with > > tryStop=false (otherwise, the JVM exit is not guaranteed as well), but we > > already use the KILL_EXIT_CODE there. > > > > пн, 1 июн. 2020 г. в 23:19, Sergey Antonov <[hidden email]>: > > > > > Hello, Kirill! > > > > > > I'd prefer to don't create a new implementation of a failure handler. We > > > already have 4 different failure handlers. We will have 6 FH (StopNodeFH > > > with exit code, StopNodeOrHaltFH with exit code), if we go your way. It > > > won't make our product simpler and easier. > > > > > > I think, we must notify a user if the cluster node had been stopped by a > > > failure handler. We can't achieve this goal without changing current FH > > > behavior. So I propose to change it and stop the process with > > > KILL_EXIT_CODE. > > > But it would be nice if users will have a flag for avoiding process stop > > > after a node failure. We can introduce a new JVM option or FH parameter > > for > > > that reason. Of course, we must highlight this change in the release > > notes. > > > > > > пн, 1 июн. 2020 г. в 19:07, ткаленко кирилл <[hidden email]>: > > > > > > > I think that [1] and [2] should not be changed, because we can kill > > > > another client code in this jvm. > > > > I suggest for these purposes to create a new [3] which will be like [1] > > > > but with a call [4] after node stop. > > > > Objections or comments? > > > > > > > > [1] - org.apache.ignite.failure.StopNodeFailureHandler > > > > [2] - org.apache.ignite.failure.StopNodeOrHaltFailureHandler > > > > [3] - org.apache.ignite.failure.FailureHandler > > > > [4] - java.lang.System#exit > > > > > > > > 25.05.2020, 22:09, "Dmitriy Pavlov" <[hidden email]>: > > > > > It seems reasonable to me. Also I would like to propose adding value > > of > > > > > Ignition.KILL_EXIT_CODE into javadoc using @value javadoc tag. > > > > > > > > > > Dev ops/admins/anyone who admins Ignite may want to know it's value > > > > without > > > > > going to Java code. > > > > > > > > > > чт, 21 мая 2020 г. в 09:39, Zhenya Stanilovsky > > > > <[hidden email]>: > > > > > > > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > > > > >> > > > > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > > > > >> [hidden email]>: > > > > >> > > > > > >> >I've created the Ignite ticket for this improvement [1]. > > > > >> > > > > > >> >[1] https://issues.apache.org/jira/browse/IGNITE-13047 > > > > >> > > > > > >> >чт, 21 мая 2020 г. в 00:46, Sergey Antonov < > > > > [hidden email] >: > > > > >> > > > > > >> >> Hello, Igniters! > > > > >> >> > > > > >> >> I'd like to discuss behaviour of Ignite process exit code if the > > > > node > > > > >> was > > > > >> >> stopped by failure handler [1][2]. At the moment ignite process > > > > returns > > > > >> >> exit code 0 after the stop in all scenarios, except runtime halt > > > by > > > > >> >> StopNodeOrHaltFH [1]. In this case, the exit code will be 130 > > [3] > > > > >> >> > > > > >> >> My proposal: always finish Ignite process with code [3], if a > > node > > > > was > > > > >> >> stopped by FH. It could be helpful for administration purposes, > > > you > > > > can > > > > >> >> distinguish normal node stop from node stop by FH on OS level. > > > > >> >> > > > > >> >> WDYT? > > > > >> >> > > > > >> >> [1] > > > > >> >> > > > > >> > > > > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeOrHaltFailureHandler.html > > > > >> >> > > > > >> >> [2] > > > > >> >> > > > > >> > > > > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/failure/StopNodeFailureHandler.html > > > > >> >> > > > > >> >> [3] > > > > >> >> > > > > >> > > > > > > > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE > > > > >> >> -- > > > > >> >> BR, Sergey Antonov > > > > >> >> > > > > >> > > > > > >> >-- > > > > >> >BR, Sergey Antonov > > > > >> > > > > > > > > > > > > > > -- > > > BR, Sergey Antonov > > > > > > > > -- > BR, Sergey Antonov |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
In reply to this post by antonovsergey93
> > 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? |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
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" <[hidden email]>: >> > 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? |
|
|
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 ткаленко кирилл <[hidden email]> 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" <[hidden email]>: > >> > 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? |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
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 <[hidden email]>: > 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 ткаленко кирилл <[hidden email]> > 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" <[hidden email]>: > > >> > 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 |
|
|
> 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 <[hidden email]> 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 <[hidden email]>: > > > 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 ткаленко кирилл <[hidden email]> > > 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" <[hidden email]>: > > > >> > 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 |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
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 <[hidden email]>: > > 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 <[hidden email]> > 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 <[hidden email]>: > > > > > 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 ткаленко кирилл <[hidden email]> > > > 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" <[hidden email]>: > > > > >> > 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 |
|
|
>> 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 <[hidden email]> 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 <[hidden email]>: > > > > 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 <[hidden email]> > > 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 <[hidden email]>: > > > > > > > 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 ткаленко кирилл <[hidden email]> > > > > 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" <[hidden email]>: > > > > > >> > 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 |
Re: [DISCUSS] Ignite process exit code on node stop by failure handler
|
|
In reply to this post by Kirill Tkalenko
Folks
I suggest closing the ticket with a comment: To kill process with exit code [1], you can use [2] by setting correct values of constructor arguments. Objections? 1 - https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE 2 - org.apache.ignite.failure.StopNodeOrHaltFailureHandler 02.06.2020, 16:59, "ткаленко кирилл" <[hidden email]>: > 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" <[hidden email]>: >>> > 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? |
«
Return to Apache Ignite Developers - Legacy Mail Archive
|
1 view|%1 views
| Free forum by Nabble | Edit this page |