I just would like to add my +1 for "kill if standalone, stop if
embedded" default option. My arguments:
1) Regarding "If Ignite hangs - it will likely be impossible to stop":
Unfortunately, it's true that Ignite can hang during stop procedure.
However, most of failures described under IEP-14 (storage IO exceptions,
death of critical system worker thread, etc) normally shouldn't turn
node into "impossible to stop" state. Turning into that state is a bug
itself. I guess that we shouldn't choose system behavior on the basis of
known bugs.
2) User might want to handle Ignite node crash before shutting down the
whole JVM - raise alert, close external resources, etc
3) IEP-14 document has important notes: "More than one Ignite node could
be started in one JVM process" and "Different nodes in one JVM process
could belong to different clusters". This is possible only in embedded
mode. I think, we shouldn't shock user by sudden JVM halt (possibly,
along with another healthy nodes) if there's a chance of successful node
stop.
Best Regards,
Ivan Rakov
On 14.03.2018 1:47, Dmitriy Setrakyan wrote:
Guys, I do not think there is an understanding here. If Ignite hangs - it
will likely be impossible to stop. So if you are suggesting "stop if
embedded", you might as well suggest "do nothing if embedded".
I have seen many Ignite deployments, embedded or not, large and small, and
in all those deployments if Ignite went into a frozen state, killing it was
the best option. Moreover, it provided the most predictable behavior. I am
not guessing here, but it seems to me that the rest of the community is
guessing.
Killing a frozen Ignite node should be a default behavior in all cases,
embedded or not. Stopping a frozen Ignite node should be a configurable
option, so a user has an ability to turn off auto-kill behavior. We should
also have a 3rd option, "stop+kill", so if stopping fails, then the process
is automatically killed (this is also a good default option).
Personally, I am OK if the default behavior is "kill" or "stop+kill", but
it should be the same default in all cases. We should stop the practice of
creating different default behaviors for the same problem. It is confusing
and hard to document.
D.
On Tue, Mar 13, 2018 at 2:19 PM, Denis Magda <dma...@apache.org> wrote:
+1 for "kill if standalone, stop if embedded" behavior. If the practice
shows that the node should be killed regardless of the mode, then it will
be an easy change. Now we are just guessing, and common sense suggests
going for "kill if standalone, stop if embedded" until we get feedback.
-
Denis
On Tue, Mar 13, 2018 at 8:30 AM, Dmitry Pavlov <dpavlov....@gmail.com>
wrote:
You are suggesting to kill the process, which was not started by Ignite,
are not you?
More consistently is to stop only those processes that are generated by
the
control of Ignite, e.g. from ignite.sh - here it is ok for me.
If we relese 'kill by default' as part of 2.5, we will end up with 2.6
emergency release to change it back, if one user will face with such
unexpected behaviour.
вт, 13 мар. 2018 г. в 18:17, Dmitriy Setrakyan <dsetrak...@apache.org>:
Dmitriy,
I think everyone is suggesting that stopping the node will likely be
impossible if Ignite is frozen. Moreover, it is very likely that all
other
apps are frozen too.
My comments are below...
On Tue, Mar 13, 2018 at 9:12 AM, Dmitry Pavlov <dpavlov....@gmail.com>
wrote:
Please consider that user application may use Ignite as optional
cache
for
some low-priority feature, but main logic is well functioning without
Ingnite. I can say, as Ignite user in the past, that it is quite real
case.
I have been a part of this project for a while, but I have never seen
Ignite used as an optional cache. Usually, Ignite is a mandatory part
of
the application, not optional.
Second real case is using several war files within one application
server,
running different logic. Some apps use Ignite, some applications -
not.
Killing application server in this case is not an option too.
Not very likely, but possible. This is not a common use case. Most
commonly
Ignite would be serving all WAR files with a common data layer.
So default should be stopping all node threads, but not kill the
process.
If user is aware process may be killed, it may setup option.
No, the default should be to kill the process. If user does not like
it,
then it should be possible to change it to stop the node first.
вт, 13 мар. 2018 г. в 15:24, Dmitriy Setrakyan <
dsetrak...@apache.org
:
On Tue, Mar 13, 2018 at 8:16 AM, Dmitry Pavlov <
dpavlov....@gmail.com>
wrote:
Dmitriy, alternative is "kill if standalone, stop if embedded"
User will be still able to set something like
-DNODE_CRASH_ACTION="kill"
if ignite.sh is not used and user accepts alternative that whole
process
would be killed if node is crashed.
Default would be 'node stop', but not hang up infinetely.
Dmitriy, if Ignite if frozen, you will not be able to stop it. The
only
guaranteed way to "un-freeze" the cluster is to kill the frozen
JVM.
On top of that, it is very likely that if you stop the "embedded"
Ignite,
the user application will not be able to function any way, so
killing
the
node does sound like a better and *safer* option.
D.
