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