My guess is that it reduces the node shutdown time. We may want to keep it
for compatibility purposes, because I'm afraid that changing the default
behaviour is not that easy.
On Tue, Oct 18, 2022 at 12:32 PM Николай Ижиков <nizhi...@apache.org> wrote:
> So why it’s default behavior?
> And why we want keep it?
>
> > 18 окт. 2022 г., в 12:27, Aleksandr Polovtsev <alexpolovt...@gmail.com>
> написал(а):
> >
> > But this is the default behaviour right now, do you mean we should change
> > it? I'm ok with that if it will not break something
> >
> > On Tue, Oct 18, 2022 at 12:13 PM Николай Ижиков <nizhi...@apache.org>
> wrote:
> >
> >>> I don't know what most people use in the real world, maybe more
> >> experienced guys can clarify that.
> >>
> >> My question is different.
> >>
> >> Why we may want to provide cancel=true?
> >> Is there any reason to support this in Ignite?
> >>
> >>> 18 окт. 2022 г., в 11:47, Aleksandr Polovtsev <alexpolovt...@gmail.com
> >
> >> написал(а):
> >>>
> >>> Thank you for the response, Nikolay. As I can see, this is the default
> >>> behaviour now (ShutdownPolicy = IMMEDIATE, cancel = true). I don't know
> >>> what most people use in the real world, maybe more experienced guys can
> >>> clarify that.
> >>>
> >>> On Tue, Oct 18, 2022 at 11:15 AM Николай Ижиков <nizhi...@apache.org>
> >> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> Why do we need «immediate»?
> >>>> Is there real-world scenarios for it?
> >>>>
> >>>> Can we do graceful or «save all possible data» shutdown always?
> >>>>
> >>>>> 18 окт. 2022 г., в 10:59, Aleksandr Polovtsev <
> alexpolovt...@gmail.com
> >>>
> >>>> написал(а):
> >>>>>
> >>>>> Hello, dear Igniters!
> >>>>>
> >>>>> I'd like to propose a refactoring of the current Shutdown Policy
> >>>> mechanism.
> >>>>> Currently, node shutdown is controlled by a bunch of flags and enums
> (I
> >>>> may
> >>>>> be missing some of them):
> >>>>>
> >>>>> 1. ShutdownPolicy enum has only two entries and is basically a flag
> >> that
> >>>>> dictates if we need to wait for the data to be backed up, so that we
> >> will
> >>>>> not lose any data when the node goes offline.
> >>>>> 2. "cancel" flag is passed to the stop method and indicates that all
> >> long
> >>>>> running jobs should be interrupted. For example, it prevents the node
> >>>>> performing a checkpoint on shutdown. I'm pretty sure this flag is
> >> nearly
> >>>>> always set to "true", because it is used by the Shutdown Hook.
> >>>>> 3. There are also a bunch of system properties that affect the
> >> shutdown:
> >>>>> * IGNITE_PDS_SKIP_CHECKPOINT_ON_NODE_STOP - disables checkpoints on
> >>>>> node stop, which heavily correlates with the "cancel" flag.
> >>>>> * IGNITE_WAIT_FOR_BACKUPS_ON_SHUTDOWN - deprecated and duplicates
> the
> >>>>> ShutdownPolicy enum
> >>>>> * IGNITE_NO_SHUTDOWN_HOOK - disables the shutdown hook. I don't know
> >>>> if
> >>>>> it is really useful.
> >>>>>
> >>>>> I think that this approach is counter intuitive and would like to
> >>>>> incorporate all aforementioned flags into the ShutdownPolicy enum.
> For
> >>>>> example, it can look as follows:
> >>>>>
> >>>>> public enum ShutdownPolicy {
> >>>>> IMMEDIATE // Stops the node and cancels all running jobs
> >>>>> GRACEFUL // Stops the node, does not cancel running jobs and waits
> >> for
> >>>>> backups
> >>>>> GRACEFUL_NO_BACKUPS // Stops the node, does not cancel running jobs,
> >>>>> does not wait for backups
> >>>>> }
> >>>>>
> >>>>> After that, the "cancel" flag and all corresponding properties can be
> >>>>> removed (apart from the IGNITE_NO_SHUTDOWN_HOOK, if it is still
> >> needed).
> >>>>>
> >>>>> Does this make sense? What do you think?
> >>>>>
> >>>>> --
> >>>>> With regards,
> >>>>> Aleksandr Polovtsev
> >>>>
> >>>>
> >>>
> >>> --
> >>> With regards,
> >>> Aleksandr Polovtsev
> >>
> >>
> >
> > --
> > With regards,
> > Aleksandr Polovtsev
>
>
--
With regards,
Aleksandr Polovtsev
