ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Date Wed, 05 Feb 2020 17:46:59 GMT
Hi Vladimir,

Yes, I'm suggesting us to enable this flag by
org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
default instead of introducing --force flag and showing any warnings.

-
Denis


On Wed, Feb 5, 2020 at 2:33 AM Vladimir Steshin <vladsz83@gmail.com> wrote:

> Hello all.
>
> Denis, which changes exactly? In current implementation of ticket [2] flag
> [1] is checked before requiring --force flag and showing any warnings. Do
> we need to set reuse-memory-on-deactivate to true by default?
>
> [1]
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
>
> [2] https://issues.apache.org/jira/browse/IGNITE-12614
>
>
> вт, 4 февр. 2020 г. в 22:45, Denis Magda <dmagda@apache.org>:
>
> > That's the best solution for this scenario. Should we readjust the
> already
> > created ticket [1] suggesting to implement the changes of Alex Scherbakov
> > instead?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12614
> >
> > -
> > Denis
> >
> >
> > On Mon, Feb 3, 2020 at 11:54 PM Alexei Scherbakov <
> > alexey.scherbakoff@gmail.com> wrote:
> >
> > > Folks,
> > >
> > > For a long time we have a flag [1]
> > >
> > > It does almost what we want here.
> > >
> > > I suggest to make this behavior default and rework it to keep data in
> > > memory as well (we already have special "recovery" mode for caches).
> > >
> > > [1]
> > >
> >
> org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE
> > >
> > >
> > >
> > > пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk <
> > alexey.goncharuk@gmail.com
> > > >:
> > >
> > > > I do not mind making this change if we explicitly and clearly define
> > what
> > > > 'new inactive state' means. What should happen if a partition is lost
> > in
> > > > inactive state? What if such node joins back the cluster after? Etc.
> > > >
> > > > пт, 31 янв. 2020 г. в 20:57, Denis Magda <dmagda@apache.org>:
> > > >
> > > > > Back up Ivan's opinion here. Initially, the activation/deactivation
> > was
> > > > > created for the baseline topology designed for cases with native
> > > > > persistence. My thinking was that the mechanism itended to prevent
> > data
> > > > > inconsistencies while nodes with data on the disk will be in the
> > > process
> > > > of
> > > > > joining the cluster.
> > > > >
> > > > > Artem, could you please update the docs bringing this to the
> > attention
> > > of
> > > > > the user community?
> > > > > https://issues.apache.org/jira/browse/IGNITE-12615
> > > > >
> > > > > AG, what if we don't purge data from memory at least for the caches
> > not
> > > > > backed by the native persistence? Is this a big deal? We can
> > certainly
> > > > put
> > > > > this off by my guts feel we'll return to this question sooner or
> > later.
> > > > >
> > > > > -
> > > > > Denis
> > > > >
> > > > >
> > > > > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin <
> vololo100@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > For me it looks like some coincidence effect. I understand that
> we
> > > get
> > > > > > such behavior because deactivation works the same way as for
> > > > > > persistent caches. Was cluster activation/deactivation designed
> and
> > > > > > described for in-memory caches? Current behavior sounds for
me a
> as
> > > > > > big risk. I expect a lot of upset users unexpectedly purged
all
> > their
> > > > > > data.
> > > > > >
> > > > > > пт, 31 янв. 2020 г. в 00:00, Alexey Goncharuk <
> > > > > alexey.goncharuk@gmail.com
> > > > > > >:
> > > > > > >
> > > > > > > Because originally the sole purpose of deactivation was
> resource
> > > > > > > deallocation.
> > > > > > >
> > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <dmagda@apache.org>:
> > > > > > >
> > > > > > > > Such a revelation for me that data is purged from
RAM if
> > someone
> > > > > > > > deactivates the cluster. Alex, do you remember why
we decided
> > to
> > > > > > implement
> > > > > > > > it this way initially?
> > > > > > > >
> > > > > > > > -
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thu, Jan 30, 2020 at 2:09 AM Alexey Goncharuk <
> > > > > > > > alexey.goncharuk@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I agree on CLI and JMX because those interfaces
can be used
> > by
> > > a
> > > > > > system
> > > > > > > > > administrator and can be invoked by mistake.
> > > > > > > > >
> > > > > > > > > As for the Java API, personally, I find it strange
to add
> > > 'force'
> > > > > or
> > > > > > > > > 'confirm' flags to it because it is very unlikely
that such
> > an
> > > > > > invocation
> > > > > > > > > is done by mistake. Such mistakes are caught
during the
> > testing
> > > > > > phase and
> > > > > > > > > developers will end up hard-coding 'true' as
a flag
> anyways.
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Best regards,
> > > Alexei Scherbakov
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message