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 <antonovserge...@gmail.com> 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 <alexey.goncha...@gmail.com>: > > > 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 <antonovserge...@gmail.com>: > > > > > 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, ткаленко кирилл <tkalkir...@yandex.ru>: > > > > > > > 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" <dpav...@apache.org>: > > > > > 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 > > > > <arzamas...@mail.ru.invalid>: > > > > > > > > > >> Thank you Sergey, as for me — very useful proposal huge +1 here. > > > > >> > > > > >> >Четверг, 21 мая 2020, 0:51 +03:00 от Sergey Antonov < > > > > >> antonovserge...@gmail.com>: > > > > >> > > > > > >> >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 < > > > > antonovserge...@gmail.com >: > > > > >> > > > > > >> >> 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
