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>
> 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
> > > 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.