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 <vololo...@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.goncha...@gmail.com
> >:
> >
> > Because originally the sole purpose of deactivation was resource
> > deallocation.
> >
> > чт, 30 янв. 2020 г. в 22:13, Denis Magda <dma...@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.goncha...@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
>

Reply via email to