What do you think if stop is default for all cases?

Kill is configurable.

We can consider enforse sockets close for 'stop'. This will allow to ignore
hang node by rest of the cluster.

ср, 14 мар. 2018 г., 1:48 Dmitriy Setrakyan <dsetrak...@apache.org>:

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

Reply via email to