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 <vlads...@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 <dma...@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.scherbak...@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.goncha...@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 <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 > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > Alexei Scherbakov > > > > > >
