Vladimir, IGNITE_REUSE_MEMORY_ON_DEACTIVATE doesn't prevent cache contents from clearing. It allows allocated memory reuse on re-activation to avoid OS specific issues if allocated heap is rather large.
You are right to create separate ticket for implementing required behavior. чт, 6 февр. 2020 г. в 16:37, Vladimir Steshin <vlads...@gmail.com>: > Or, is flag [1] is actual only for persistence mode? Related ticket [2] is > completely about disabled persistence. > If previous assumption is right, I think, we can involve flag [1] in ticket > [2]. > > [1] > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > [2] https://issues.apache.org/jira/browse/IGNITE-12614 > > чт, 6 февр. 2020 г. в 16:10, Vladimir Steshin <vlads...@gmail.com>: > > > Denis, Alexei, > > > > Regarding usage of flag > > > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > [1] > > > > When enabled, I think the following test should work. But it fails. > > > > //---------------------------------------------------------------- > > @Test > > public void testDataPresent() throws Exception { > > System.setProperty(IGNITE_REUSE_MEMORY_ON_DEACTIVATE, "true"); > > > > IgniteEx i = startGrid(0); > > > > assertFalse( > > > i.configuration().getDataStorageConfiguration().getDefaultDataRegionConfiguration() > > .isPersistenceEnabled() ); > > > > String name = "non-persistent-cache"; > > > > i.createCache(name).put(1L, 1L); > > > > assertEquals(1L, i.cache(name).get(1L)); > > > > i.cluster().state(ClusterState.INACTIVE); > > i.cluster().state(ClusterState.ACTIVE); > > > > assertEquals(1L, i.cache(name).get(1L)); //Assertion error here! > > } > > //---------------------------------------------------------------- > > > > > > Several notes: > > > > - IgniteCacheDatabaseSharedManager#reuseMemory > > is true > > - IgniteCacheDatabaseSharedManager#onDeActivate(boolean shutdown) > > is called with shutdown == false > > - PageMemoryNoStoreImpl#stop(booleam deallocate) > > is called with deallocate == false > > > > But the cache from the test still has zero size after reactivation. > > > > Is flag [1] disabled by default because it is not implemented / doesn't > > work? Do we need to skip it in current ticket and rise new one? > > > > ср, 5 февр. 2020 г. в 21:05, Denis Magda <dma...@apache.org>: > > > >> I believe there might be a consistency-related reason why this flag was > >> disabled by default for caches that store data in Ignite native > >> persistence. I hope, Alex Goncharuk or Scherbakov can shed some light on > >> this. > >> > >> As for the memory-only caches or caches backed up by a CacheStore such > as > >> an RDBMS, enabling of the flag should be harmless. Once we do this, > we'll > >> eliminate the need to load the data back into the cluster which can be a > >> time-consuming operation depending on the data volume. > >> > >> > >> - > >> Denis > >> > >> > >> On Wed, Feb 5, 2020 at 11:58 AM Vladimir Steshin <vlads...@gmail.com> > >> wrote: > >> > >> > Denis, but why reuse-data-on-deactivate was disabled by default? There > >> > should be a reason for that. Any data consistency issues when node > gets > >> > activated anew? We may use both solutions because the flag can be > >> switched > >> > off again. > >> > > >> > ср, 5 февр. 2020 г. в 20:47, Denis Magda <dma...@apache.org>: > >> > > >> > > 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 > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > -- Best regards, Alexei Scherbakov
