+1, this is exactly what I want.
I'm fine with either IMMEDIATE or DEFAULT.
вт, 9 июн. 2020 г. в 19:41, Ivan Rakov :
> Vlad,
>
> +1, that's what I mean.
> We don't need either or dedicated USE_STATIC_CONFIGURATION in case
> the user will be able to retrieve current shutdown policy and apply the
Vlad,
+1, that's what I mean.
We don't need either or dedicated USE_STATIC_CONFIGURATION in case
the user will be able to retrieve current shutdown policy and apply the one
he needs.
My only requirement is that ignite.cluster().getShutdownPolicy() should
return a statically configured value {@lin
Hi,
ignite.cluster().setShutdownPolicy(null); // Clear dynamic value and switch
to statically configured.
I do not understand why we need it. if user want to change configuration to
any other value he set it explicitly.
We can to add warning on start when static option does not math to dynamic
(d
Alex,
Also shutdown policy must be always consistent on the grid or unintentional
> data loss is possible if two nodes are stopping simultaneously with
> different policies.
Totally agree.
Let's use shutdownPolicy=DEFAULT|GRACEFUL, as was proposed by me earlier.
I'm ok with GRACEFUL instead o
Alex,
I'm not sure there is a problem at all, because user can always query the
> current policy, and a javadoc can describe such behavior clearly.
What will the query method return if the static policy is not overridden?
If we decide to avoid adding dedicated USE_STATIC_CONFIGURATION value,
sema
Ivan,
Using an additional enum on public API for resetting dynamic value looks a
little bit dirty for me.
I'm not sure there is a problem at all, because user can always query the
current policy, and a javadoc can describe such behavior clearly.
If you really insist maybe use null to reset policy
Something went wrong with gmail formatting. Resending my reply.
Alex,
Also shutdown policy must be always consistent on the grid or unintentional
> data loss is possible if two nodes are stopping simultaneously with
> different policies.
Totally agree.
Let's use shutdownPolicy=DEFAULT|GRACEFUL
Alex,
Also shutdown policy must be always consistent on the grid or unintentional
> data loss is possible if two nodes are stopping simultaneously with
> different policies.
Totally agree.
Let's use shutdownPolicy=DEFAULT|GRACEFUL, as was proposed by me earlier.
I'm ok with GRACEFUL instead o
Ivan Rakov,
Your proposal overall looks good to me. My comments:
1. I would avoid adding such a method, because it will be impossible to
change it in the future if some more shutdown policies will be introduced
later.
Also shutdown policy must be always consistent on the grid or unintentional
dat
Vlad, thanks for starting this discussion.
I'll try to clarify the motivation for this change as I see it.
In general, Ignite clusters are vulnerable to the data loss. Of course, we
have configurable PartitionLossPolicy, which allows to handle data loss
safely and mitigate its consequences. But be
> I see no relation between possible data loss on shutdown and waiting for
> some jobs to complete.
Yes, I do not think that is.
More over that I want to union waiting of jobs and waiting rebalance in one
shutdown policy. Rather, these various shutdown types mean various types of
waiting.
IMMEDIAT
Graceful policy should only be applicable to caches having a number of
backups > 0.
пн, 8 июн. 2020 г. в 14:54, Alexei Scherbakov :
> V.Pyatkov
>
>
> While I agree we need a way to prevent unintentional data loss on
> shutdown, I do not like the proposed shutdown flags enum.
> I see no relation b
V.Pyatkov
While I agree we need a way to prevent unintentional data loss on shutdown,
I do not like the proposed shutdown flags enum.
I see no relation between possible data loss on shutdown and waiting for
some jobs to complete.
All we need is a new method (duplicated by system property), like
13 matches
Mail list logo
