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
> > > > > >
> > > > >
> > > >
> > >
> >
>
