Data vanished from cluster after INACTIVE/ACTIVE switch

[Steshin Vladimir]

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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>
> > > 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 <[hidden email]>:
> > > >
> > > > > 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 <
> > > > > [hidden email]> 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 <
> > > > > [hidden email]
> > > > > > >:
> > > > > >
> > > > > > > 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 <[hidden email]>:
> > > > > > >
> > > > > > > > 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 <
> > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > > [hidden email]
> > > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > Because originally the sole purpose of deactivation was
> > > > resource
> > > > > > > > > > deallocation.
> > > > > > > > > >
> > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <
> > [hidden email]
> > > >:
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Steshin Vladimir]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>
>> 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 <[hidden email]>:
>> >
>> > > 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 <[hidden email]>
>> > > 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 <[hidden email]>:
>> > > >
>> > > > > 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 <
>> > > > > [hidden email]> 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 <
>> > > > > [hidden email]
>> > > > > > >:
>> > > > > >
>> > > > > > > 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 <[hidden email]>:
>> > > > > > >
>> > > > > > > > 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 <
>> > > > [hidden email]>
>> > > > > > > > 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 <
>> > > > > > > > [hidden email]
>> > > > > > > > > >:
>> > > > > > > > > >
>> > > > > > > > > > Because originally the sole purpose of deactivation was
>> > > > resource
>> > > > > > > > > > deallocation.
>> > > > > > > > > >
>> > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <
>> > [hidden email]
>> > > >:
>> > > > > > > > > >
>> > > > > > > > > > > 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 <
>> > > > > > > > > > > [hidden email]>
>> > > > > > > > > > > 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
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

[Alexei Scherbakov]

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 <[hidden email]>:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> >> 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 <[hidden email]>
> >> 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 <[hidden email]>:
> >> >
> >> > > 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 <[hidden email]
> >
> >> > > 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 <[hidden email]>:
> >> > > >
> >> > > > > 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 <
> >> > > > > [hidden email]> 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 <
> >> > > > > [hidden email]
> >> > > > > > >:
> >> > > > > >
> >> > > > > > > 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 <[hidden email]
> >:
> >> > > > > > >
> >> > > > > > > > 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 <
> >> > > > [hidden email]>
> >> > > > > > > > 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 <
> >> > > > > > > > [hidden email]
> >> > > > > > > > > >:
> >> > > > > > > > > >
> >> > > > > > > > > > Because originally the sole purpose of deactivation
> was
> >> > > > resource
> >> > > > > > > > > > deallocation.
> >> > > > > > > > > >
> >> > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <
> >> > [hidden email]
> >> > > >:
> >> > > > > > > > > >
> >> > > > > > > > > > > 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 <
> >> > > > > > > > > > > [hidden email]>
> >> > > > > > > > > > > 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

[Steshin Vladimir]

Ok. Then we are at the beginning. To prevent unexpected data loss on
deactivation CLI and JMX should require 'force' flag. If there are no extra
proposals I'm going to finish the pull request.

чт, 6 февр. 2020 г. в 21:43, Alexei Scherbakov <[hidden email]
>:

> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > >
> > >> 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 <[hidden email]>
> > >> 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 <[hidden email]>:
> > >> >
> > >> > > 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 <
> [hidden email]
> > >
> > >> > > 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 <[hidden email]>:
> > >> > > >
> > >> > > > > 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 <
> > >> > > > > [hidden email]> 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 <
> > >> > > > > [hidden email]
> > >> > > > > > >:
> > >> > > > > >
> > >> > > > > > > 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 <
> [hidden email]
> > >:
> > >> > > > > > >
> > >> > > > > > > > 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 <
> > >> > > > [hidden email]>
> > >> > > > > > > > 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 <
> > >> > > > > > > > [hidden email]
> > >> > > > > > > > > >:
> > >> > > > > > > > > >
> > >> > > > > > > > > > Because originally the sole purpose of deactivation
> > was
> > >> > > > resource
> > >> > > > > > > > > > deallocation.
> > >> > > > > > > > > >
> > >> > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <
> > >> > [hidden email]
> > >> > > >:
> > >> > > > > > > > > >
> > >> > > > > > > > > > > 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 <
> > >> > > > > > > > > > > [hidden email]>
> > >> > > > > > > > > > > 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
>

[Nikolay Izhikov-2]

> To prevent unexpected data loss on
deactivation CLI and JMX should require 'force' flag

 Vladimir, please, go for it.


пт, 7 февр. 2020 г., 11:19 Vladimir Steshin <[hidden email]>:

> Ok. Then we are at the beginning. To prevent unexpected data loss on
> deactivation CLI and JMX should require 'force' flag. If there are no extra
> proposals I'm going to finish the pull request.
>
> чт, 6 февр. 2020 г. в 21:43, Alexei Scherbakov <
> [hidden email]
> >:
>
> > 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>:
> > > >
> > > >> 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 <
> [hidden email]>
> > > >> 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 <[hidden email]>:
> > > >> >
> > > >> > > 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 <
> > [hidden email]
> > > >
> > > >> > > 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 <[hidden email]>:
> > > >> > > >
> > > >> > > > > 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 <
> > > >> > > > > [hidden email]> 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 <
> > > >> > > > > [hidden email]
> > > >> > > > > > >:
> > > >> > > > > >
> > > >> > > > > > > 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 <
> > [hidden email]
> > > >:
> > > >> > > > > > >
> > > >> > > > > > > > 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 <
> > > >> > > > [hidden email]>
> > > >> > > > > > > > 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 <
> > > >> > > > > > > > [hidden email]
> > > >> > > > > > > > > >:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > Because originally the sole purpose of
> deactivation
> > > was
> > > >> > > > resource
> > > >> > > > > > > > > > deallocation.
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <
> > > >> > [hidden email]
> > > >> > > >:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > > 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 <
> > > >> > > > > > > > > > > [hidden email]>
> > > >> > > > > > > > > > > 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
> >
>

[Steshin Vladimir]

Hi, folks.

Another question has raised. Can I remove / rename / bring substitution for
IgniteMXBean#active(boolean active) ? Or at least to deprecate?

The problem is that it interferes with Ignite#active(boolean active). Same
signature for different interfaces. And only one implementation:
IgniteKernal#active(boolean). We decided not to touch internal calls to
cluster deactivation. We warn user only at manual deactivation via CLI and
JMX. In the code and tests one can find many usages of
Ignite#active(boolean active). I can’t, for example, throw an exception
from it. Several tests will fail. Including C++ and C# ones. But this also
means IgniteMXBean#active(boolean active) won’t warn user of the data loss
too. Adding new method to the JMX bean won’t solve the problem. Old
active(boolean) comes first, clearly seen and is obvious to use.

What is the best practice for cases like this?

пт, 7 февр. 2020 г. в 11:23, Nikolay Izhikov <[hidden email]>:

> > To prevent unexpected data loss on
> deactivation CLI and JMX should require 'force' flag
>
>  Vladimir, please, go for it.
>
>
> пт, 7 февр. 2020 г., 11:19 Vladimir Steshin <[hidden email]>:
>
> > Ok. Then we are at the beginning. To prevent unexpected data loss on
> > deactivation CLI and JMX should require 'force' flag. If there are no
> extra
> > proposals I'm going to finish the pull request.
> >
> > чт, 6 февр. 2020 г. в 21:43, Alexei Scherbakov <
> > [hidden email]
> > >:
> >
> > > 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>:
> > > >
> > > > > 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 <[hidden email]>:
> > > > >
> > > > >> 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 <
> > [hidden email]>
> > > > >> 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 <[hidden email]>:
> > > > >> >
> > > > >> > > 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 <
> > > [hidden email]
> > > > >
> > > > >> > > 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 <[hidden email]
> >:
> > > > >> > > >
> > > > >> > > > > 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 <
> > > > >> > > > > [hidden email]> 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 <
> > > > >> > > > > [hidden email]
> > > > >> > > > > > >:
> > > > >> > > > > >
> > > > >> > > > > > > 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 <
> > > [hidden email]
> > > > >:
> > > > >> > > > > > >
> > > > >> > > > > > > > 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 <
> > > > >> > > > [hidden email]>
> > > > >> > > > > > > > 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 <
> > > > >> > > > > > > > [hidden email]
> > > > >> > > > > > > > > >:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > Because originally the sole purpose of
> > deactivation
> > > > was
> > > > >> > > > resource
> > > > >> > > > > > > > > > deallocation.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <
> > > > >> > [hidden email]
> > > > >> > > >:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > > 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 <
> > > > >> > > > > > > > > > > [hidden email]>
> > > > >> > > > > > > > > > > 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
> > >
> >
>

[Steshin Vladimir]

Hello, everyone.



I’d like to propose to make behavior of cluster deactivation the same
independently on usage type: in code or manually with control.sh or JMX.
Let’s put it in one place like IgniteCluster#state(ClusterState newState,
boolean force) and require forced call for in-memory data.

While I was doing the ticket I realized that the suggested previously
solution cannot be complete. To prevent data loss via JMX I would need to
stop executing IgniteMXBean#active(false). But this causes stopping of
Ignite#active(false) too. The problem relies in single implementation for
both interfaces in IgniteKernal#active(boolean). It has to act differently
depending on where it is called from: JMX/CLI or code.



            Any thoughts?

чт, 30 янв. 2020 г. в 13:08, Alexey Goncharuk <[hidden email]>:

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

[Nikolay Izhikov-2]

Hello, Vladimir.

I think we should do the following:

* Update Ignite documentation and write down the fact that in-memory cache cleared on deactivation.
* Disallow, by default, deactivation of the cluster that has in-memory cache with proper error message
        «Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!»
* Add «—force» flag to deactivate command so administrator can force deactivation for cluster that has both - persistent and in-memory caches configured.

Changes in the source code should include:

1. JMX beans - IgniteMXBean.
2. Java API - Ignite#active and Ignite#cluster#state - because active method have the same implementation as `IgniteMBBean#active`
3. CLI utility - control.sh

Igniters, what do you think?

> 13 февр. 2020 г., в 14:19, Vladimir Steshin <[hidden email]> написал(а):
>
> Hello, everyone.
>
>
>
> I’d like to propose to make behavior of cluster deactivation the same
> independently on usage type: in code or manually with control.sh or JMX.
> Let’s put it in one place like IgniteCluster#state(ClusterState newState,
> boolean force) and require forced call for in-memory data.
>
> While I was doing the ticket I realized that the suggested previously
> solution cannot be complete. To prevent data loss via JMX I would need to
> stop executing IgniteMXBean#active(false). But this causes stopping of
> Ignite#active(false) too. The problem relies in single implementation for
> both interfaces in IgniteKernal#active(boolean). It has to act differently
> depending on where it is called from: JMX/CLI or code.
>
>
>
>            Any thoughts?
>
> чт, 30 янв. 2020 г. в 13:08, Alexey Goncharuk <[hidden email]>:
>
>> 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.
>>

[Nikita Amelchev]

Hi, guys.

I suggest mark as deprecated the IgniteMXBean#active(boolean) method.
The Ignite#active(boolean),  IgniteMXBean#active(),
IgniteCluster#active(boolean) methods already deprecated and told to
use the #state(ClusterState)} instead.

Should the old IgniteMXBean#state(ClusterState) method throw a
not-safe deactivation exception? Or it should just be marked as
deprecated?

пт, 14 февр. 2020 г. в 12:18, Nikolay Izhikov <[hidden email]>:

>
> Hello, Vladimir.
>
> I think we should do the following:
>
> * Update Ignite documentation and write down the fact that in-memory cache cleared on deactivation.
> * Disallow, by default, deactivation of the cluster that has in-memory cache with proper error message
>         «Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!»
> * Add «—force» flag to deactivate command so administrator can force deactivation for cluster that has both - persistent and in-memory caches configured.
>
> Changes in the source code should include:
>
> 1. JMX beans - IgniteMXBean.
> 2. Java API - Ignite#active and Ignite#cluster#state - because active method have the same implementation as `IgniteMBBean#active`
> 3. CLI utility - control.sh
>
> Igniters, what do you think?
>
> > 13 февр. 2020 г., в 14:19, Vladimir Steshin <[hidden email]> написал(а):
> >
> > Hello, everyone.
> >
> >
> >
> > I’d like to propose to make behavior of cluster deactivation the same
> > independently on usage type: in code or manually with control.sh or JMX.
> > Let’s put it in one place like IgniteCluster#state(ClusterState newState,
> > boolean force) and require forced call for in-memory data.
> >
> > While I was doing the ticket I realized that the suggested previously
> > solution cannot be complete. To prevent data loss via JMX I would need to
> > stop executing IgniteMXBean#active(false). But this causes stopping of
> > Ignite#active(false) too. The problem relies in single implementation for
> > both interfaces in IgniteKernal#active(boolean). It has to act differently
> > depending on where it is called from: JMX/CLI or code.
> >
> >
> >
> >            Any thoughts?
> >
> > чт, 30 янв. 2020 г. в 13:08, Alexey Goncharuk <[hidden email]>:
> >
> >> 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 wishes,
Amelchev Nikita

[Alexey Goncharuk]

Igniters,

Do we really need the confirmation flag on the public API? I absolutely
agree on the CLI and MXBean, but what is the reason for the flag in the
API? It will be specified at the compile time anyway and does not prevent
any user error.
From the implementation point of view I see no contradiction - we can add
the new method to the MXBean, but nothing forces us to add it to Ignite
interface - those interfaces are not related.

[Nikolay Izhikov-2]

Alexey.

The issue with the existing method.

Single implementation for both Ignite#active(boolean) and IgniteMXBean#active(boolean)
Should it continue to silently clears in-memory caches?

> 14 февр. 2020 г., в 15:20, Alexey Goncharuk <[hidden email]> написал(а):
>
> Igniters,
>
> Do we really need the confirmation flag on the public API? I absolutely
> agree on the CLI and MXBean, but what is the reason for the flag in the
> API? It will be specified at the compile time anyway and does not prevent
> any user error.
> From the implementation point of view I see no contradiction - we can add
> the new method to the MXBean, but nothing forces us to add it to Ignite
> interface - those interfaces are not related.

[Steshin Vladimir]

Alexey, adding a new method with force flag means old methods change their
behavior: they are considered as executed without ‘force‘ flag and can fail
to prevent data loss. Ignite and IgniteMXBean are different interfaces.
Unfortunately, they have same method

void  active(boolean active)

When executed as IgniteMXBean it should fail if user can lose data. When
executed from code via interface Ignite probably not. To solve this I
suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST and
other API.

пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <[hidden email]>:

> Igniters,
>
> Do we really need the confirmation flag on the public API? I absolutely
> agree on the CLI and MXBean, but what is the reason for the flag in the
> API? It will be specified at the compile time anyway and does not prevent
> any user error.
> From the implementation point of view I see no contradiction - we can add
> the new method to the MXBean, but nothing forces us to add it to Ignite
> interface - those interfaces are not related.
>

[slava.koptilin]

Hello Vladimir,

> adding a new method with force flag means old methods change their
behavior:
I don't think that changing the behavior of public API is the right way.
Moreover, I agree with Alex that there is no need to introduce a
"confirmation" flag to the java API.

Thanks,
S.

пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[hidden email]>:

> Alexey, adding a new method with force flag means old methods change their
> behavior: they are considered as executed without ‘force‘ flag and can fail
> to prevent data loss. Ignite and IgniteMXBean are different interfaces.
> Unfortunately, they have same method
>
> void  active(boolean active)
>
> When executed as IgniteMXBean it should fail if user can lose data. When
> executed from code via interface Ignite probably not. To solve this I
> suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST and
> other API.
>
> пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <[hidden email]
> >:
>
> > Igniters,
> >
> > Do we really need the confirmation flag on the public API? I absolutely
> > agree on the CLI and MXBean, but what is the reason for the flag in the
> > API? It will be specified at the compile time anyway and does not prevent
> > any user error.
> > From the implementation point of view I see no contradiction - we can add
> > the new method to the MXBean, but nothing forces us to add it to Ignite
> > interface - those interfaces are not related.
> >
>

[Nikolay Izhikov-2]

Vyacheslav.

What is your suggestion for the API?

Single implementation for both Ignite#active(boolean) and IgniteMXBean#active(boolean)
Should public java API continue to silently clears in-memory caches?

> 14 февр. 2020 г., в 15:56, Вячеслав Коптилин <[hidden email]> написал(а):
>
> Hello Vladimir,
>
>> adding a new method with force flag means old methods change their
> behavior:
> I don't think that changing the behavior of public API is the right way.
> Moreover, I agree with Alex that there is no need to introduce a
> "confirmation" flag to the java API.
>
> Thanks,
> S.
>
> пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[hidden email]>:
>
>> Alexey, adding a new method with force flag means old methods change their
>> behavior: they are considered as executed without ‘force‘ flag and can fail
>> to prevent data loss. Ignite and IgniteMXBean are different interfaces.
>> Unfortunately, they have same method
>>
>> void  active(boolean active)
>>
>> When executed as IgniteMXBean it should fail if user can lose data. When
>> executed from code via interface Ignite probably not. To solve this I
>> suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST and
>> other API.
>>
>> пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <[hidden email]
>>> :
>>
>>> Igniters,
>>>
>>> Do we really need the confirmation flag on the public API? I absolutely
>>> agree on the CLI and MXBean, but what is the reason for the flag in the
>>> API? It will be specified at the compile time anyway and does not prevent
>>> any user error.
>>> From the implementation point of view I see no contradiction - we can add
>>> the new method to the MXBean, but nothing forces us to add it to Ignite
>>> interface - those interfaces are not related.
>>>
>>

[Steshin Vladimir]

Вячеслав, Hi.

Even if previous behavior is controversial? It allows to erase data
suddenly. I would suggest to slightly change API of IgniteMXBean. It would
solve the problem of single implementation IgniteKernal#active(boolean).
But changing of API is prohibited. Another solution is to extract
implementation of IgniteMXBean from IgniteKernal. I believe this approach
is too bulky.  How often Ignite#active(false) is used outside the tests?
What is so wrong to use new IgniteCluster(INACTIVE, force:true)?


To the point, the PR is here:

пт, 14 февр. 2020 г. в 15:57, Вячеслав Коптилин <[hidden email]>:

> Hello Vladimir,
>
> > adding a new method with force flag means old methods change their
> behavior:
> I don't think that changing the behavior of public API is the right way.
> Moreover, I agree with Alex that there is no need to introduce a
> "confirmation" flag to the java API.
>
> Thanks,
> S.
>
> пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[hidden email]>:
>
> > Alexey, adding a new method with force flag means old methods change
> their
> > behavior: they are considered as executed without ‘force‘ flag and can
> fail
> > to prevent data loss. Ignite and IgniteMXBean are different interfaces.
> > Unfortunately, they have same method
> >
> > void  active(boolean active)
> >
> > When executed as IgniteMXBean it should fail if user can lose data. When
> > executed from code via interface Ignite probably not. To solve this I
> > suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST and
> > other API.
> >
> > пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <
> [hidden email]
> > >:
> >
> > > Igniters,
> > >
> > > Do we really need the confirmation flag on the public API? I absolutely
> > > agree on the CLI and MXBean, but what is the reason for the flag in the
> > > API? It will be specified at the compile time anyway and does not
> prevent
> > > any user error.
> > > From the implementation point of view I see no contradiction - we can
> add
> > > the new method to the MXBean, but nothing forces us to add it to Ignite
> > > interface - those interfaces are not related.
> > >
> >
>

[Steshin Vladimir]

* The pr:  https://github.com/apache/ignite/pull/7358

One can see the solution closer.

пт, 14 февр. 2020 г. в 15:57, Вячеслав Коптилин <[hidden email]>:

> Hello Vladimir,
>
> > adding a new method with force flag means old methods change their
> behavior:
> I don't think that changing the behavior of public API is the right way.
> Moreover, I agree with Alex that there is no need to introduce a
> "confirmation" flag to the java API.
>
> Thanks,
> S.
>
> пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[hidden email]>:
>
> > Alexey, adding a new method with force flag means old methods change
> their
> > behavior: they are considered as executed without ‘force‘ flag and can
> fail
> > to prevent data loss. Ignite and IgniteMXBean are different interfaces.
> > Unfortunately, they have same method
> >
> > void  active(boolean active)
> >
> > When executed as IgniteMXBean it should fail if user can lose data. When
> > executed from code via interface Ignite probably not. To solve this I
> > suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST and
> > other API.
> >
> > пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <
> [hidden email]
> > >:
> >
> > > Igniters,
> > >
> > > Do we really need the confirmation flag on the public API? I absolutely
> > > agree on the CLI and MXBean, but what is the reason for the flag in the
> > > API? It will be specified at the compile time anyway and does not
> prevent
> > > any user error.
> > > From the implementation point of view I see no contradiction - we can
> add
> > > the new method to the MXBean, but nothing forces us to add it to Ignite
> > > interface - those interfaces are not related.
> > >
> >
>

[slava.koptilin]

Hello Nikolay,

> Should public java API continue to silently clear in-memory caches?
Let's assume that I have a mixed cluster with persistent cache and
in-memory cache which is backed by 3-rd party persistence. I see no reason
to throw an exception in that case at least.
Anyway, this fact should be clearly stated in the Javadoc and documentation
of course.

> What is your suggestion for the API?
I think we are talking about JMX methods. Am I correct? Is it possible to
add new methods as follows: activateCluster()/deactivateCluster() and
deprecate IgniteMXBean#active(boolean)?
Does this make sense? Am I missing something?

Thanks,
S.

пт, 14 февр. 2020 г. в 16:17, Nikolay Izhikov <[hidden email]>:

> Vyacheslav.
>
> What is your suggestion for the API?
>
> Single implementation for both Ignite#active(boolean) and
> IgniteMXBean#active(boolean)
> Should public java API continue to silently clears in-memory caches?
>
>
> > 14 февр. 2020 г., в 15:56, Вячеслав Коптилин <[hidden email]>
> написал(а):
> >
> > Hello Vladimir,
> >
> >> adding a new method with force flag means old methods change their
> > behavior:
> > I don't think that changing the behavior of public API is the right way.
> > Moreover, I agree with Alex that there is no need to introduce a
> > "confirmation" flag to the java API.
> >
> > Thanks,
> > S.
> >
> > пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[hidden email]>:
> >
> >> Alexey, adding a new method with force flag means old methods change
> their
> >> behavior: they are considered as executed without ‘force‘ flag and can
> fail
> >> to prevent data loss. Ignite and IgniteMXBean are different interfaces.
> >> Unfortunately, they have same method
> >>
> >> void  active(boolean active)
> >>
> >> When executed as IgniteMXBean it should fail if user can lose data. When
> >> executed from code via interface Ignite probably not. To solve this I
> >> suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST
> and
> >> other API.
> >>
> >> пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <
> [hidden email]
> >>> :
> >>
> >>> Igniters,
> >>>
> >>> Do we really need the confirmation flag on the public API? I absolutely
> >>> agree on the CLI and MXBean, but what is the reason for the flag in the
> >>> API? It will be specified at the compile time anyway and does not
> prevent
> >>> any user error.
> >>> From the implementation point of view I see no contradiction - we can
> add
> >>> the new method to the MXBean, but nothing forces us to add it to Ignite
> >>> interface - those interfaces are not related.
> >>>
> >>
>
>

[Nikolay Izhikov-2]

Vyacheslav.


Let’s see what we got for now:

```
Ignite {

    @Deprecated
    public boolean active();

    @Deprecated
    public void active(boolean active);
}

IgniteMXBean {
    @Deprecated
    public boolean active();

    public void active(boolean active); //Please, note, this method is not deprecated. It has the same implementation as Ignite#active(boolean)
}

IgniteCluster {
    @Deprecated
    public boolean active();

    @Deprecated
    public void active(boolean active);

    public ClusterState state();

    public void state(ClusterState newState) throws IgniteException;
}
```

This issue with the IgniteMXBean#active(boolean) - it has the same implementation(IgniteKernal#active) as Ignite#active.
We can’t change IgniteMXBean#active without changing Ignite#active.

Moreover, for now, we already have an API mess for cluster activation.
If we introduce different behavior for the different interfaces(java, JMX) it will confuse users even more.

> I see no reason to throw an exception in that case at least.

Users(and even Ignite PMCs) doesn’t expect that in-memory cache will be cleared on deactivation.
I think we should notify users about this detail in very clear fashion - require explicit confirmation for the operation.

> Anyway, this fact should be clearly stated in the Javadoc and documentation of course.

This is default requirement for the improvement.
It will be done.

> 14 февр. 2020 г., в 17:36, Вячеслав Коптилин <[hidden email]> написал(а):
>
> Hello Nikolay,
>
>> Should public java API continue to silently clear in-memory caches?
> Let's assume that I have a mixed cluster with persistent cache and
> in-memory cache which is backed by 3-rd party persistence. I see no reason
> to throw an exception in that case at least.
> Anyway, this fact should be clearly stated in the Javadoc and documentation
> of course.
>
>> What is your suggestion for the API?
> I think we are talking about JMX methods. Am I correct? Is it possible to
> add new methods as follows: activateCluster()/deactivateCluster() and
> deprecate IgniteMXBean#active(boolean)?
> Does this make sense? Am I missing something?
>
> Thanks,
> S.
>
> пт, 14 февр. 2020 г. в 16:17, Nikolay Izhikov <[hidden email]>:
>
>> Vyacheslav.
>>
>> What is your suggestion for the API?
>>
>> Single implementation for both Ignite#active(boolean) and
>> IgniteMXBean#active(boolean)
>> Should public java API continue to silently clears in-memory caches?
>>
>>
>>> 14 февр. 2020 г., в 15:56, Вячеслав Коптилин <[hidden email]>
>> написал(а):
>>>
>>> Hello Vladimir,
>>>
>>>> adding a new method with force flag means old methods change their
>>> behavior:
>>> I don't think that changing the behavior of public API is the right way.
>>> Moreover, I agree with Alex that there is no need to introduce a
>>> "confirmation" flag to the java API.
>>>
>>> Thanks,
>>> S.
>>>
>>> пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[hidden email]>:
>>>
>>>> Alexey, adding a new method with force flag means old methods change
>> their
>>>> behavior: they are considered as executed without ‘force‘ flag and can
>> fail
>>>> to prevent data loss. Ignite and IgniteMXBean are different interfaces.
>>>> Unfortunately, they have same method
>>>>
>>>> void  active(boolean active)
>>>>
>>>> When executed as IgniteMXBean it should fail if user can lose data. When
>>>> executed from code via interface Ignite probably not. To solve this I
>>>> suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST
>> and
>>>> other API.
>>>>
>>>> пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <
>> [hidden email]
>>>>> :
>>>>
>>>>> Igniters,
>>>>>
>>>>> Do we really need the confirmation flag on the public API? I absolutely
>>>>> agree on the CLI and MXBean, but what is the reason for the flag in the
>>>>> API? It will be specified at the compile time anyway and does not
>> prevent
>>>>> any user error.
>>>>> From the implementation point of view I see no contradiction - we can
>> add
>>>>> the new method to the MXBean, but nothing forces us to add it to Ignite
>>>>> interface - those interfaces are not related.
>>>>>
>>>>
>>
>>

[Nikolay Izhikov-2]

Soory.

I forgot two more methods

IgniteMXBean {
    @Deprecated
    public String clusterState();

    public void clusterState(String state);
}

> 14 февр. 2020 г., в 17:50, Nikolay Izhikov <[hidden email]> написал(а):
>
> Vyacheslav.
>
>
> Let’s see what we got for now:
>
> ```
> Ignite {
>
>    @Deprecated
>    public boolean active();
>
>    @Deprecated
>    public void active(boolean active);
> }
>
> IgniteMXBean {
>    @Deprecated
>    public boolean active();
>
>    public void active(boolean active); //Please, note, this method is not deprecated. It has the same implementation as Ignite#active(boolean)
> }
>
> IgniteCluster {
>    @Deprecated
>    public boolean active();
>
>    @Deprecated
>    public void active(boolean active);
>
>    public ClusterState state();
>
>    public void state(ClusterState newState) throws IgniteException;
> }
> ```
>
> This issue with the IgniteMXBean#active(boolean) - it has the same implementation(IgniteKernal#active) as Ignite#active.
> We can’t change IgniteMXBean#active without changing Ignite#active.
>
> Moreover, for now, we already have an API mess for cluster activation.
> If we introduce different behavior for the different interfaces(java, JMX) it will confuse users even more.
>
>> I see no reason to throw an exception in that case at least.
>
> Users(and even Ignite PMCs) doesn’t expect that in-memory cache will be cleared on deactivation.
> I think we should notify users about this detail in very clear fashion - require explicit confirmation for the operation.
>
>> Anyway, this fact should be clearly stated in the Javadoc and documentation of course.
>
> This is default requirement for the improvement.
> It will be done.
>
>
>
>> 14 февр. 2020 г., в 17:36, Вячеслав Коптилин <[hidden email]> написал(а):
>>
>> Hello Nikolay,
>>
>>> Should public java API continue to silently clear in-memory caches?
>> Let's assume that I have a mixed cluster with persistent cache and
>> in-memory cache which is backed by 3-rd party persistence. I see no reason
>> to throw an exception in that case at least.
>> Anyway, this fact should be clearly stated in the Javadoc and documentation
>> of course.
>>
>>> What is your suggestion for the API?
>> I think we are talking about JMX methods. Am I correct? Is it possible to
>> add new methods as follows: activateCluster()/deactivateCluster() and
>> deprecate IgniteMXBean#active(boolean)?
>> Does this make sense? Am I missing something?
>>
>> Thanks,
>> S.
>>
>> пт, 14 февр. 2020 г. в 16:17, Nikolay Izhikov <[hidden email]>:
>>
>>> Vyacheslav.
>>>
>>> What is your suggestion for the API?
>>>
>>> Single implementation for both Ignite#active(boolean) and
>>> IgniteMXBean#active(boolean)
>>> Should public java API continue to silently clears in-memory caches?
>>>
>>>
>>>> 14 февр. 2020 г., в 15:56, Вячеслав Коптилин <[hidden email]>
>>> написал(а):
>>>>
>>>> Hello Vladimir,
>>>>
>>>>> adding a new method with force flag means old methods change their
>>>> behavior:
>>>> I don't think that changing the behavior of public API is the right way.
>>>> Moreover, I agree with Alex that there is no need to introduce a
>>>> "confirmation" flag to the java API.
>>>>
>>>> Thanks,
>>>> S.
>>>>
>>>> пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[hidden email]>:
>>>>
>>>>> Alexey, adding a new method with force flag means old methods change
>>> their
>>>>> behavior: they are considered as executed without ‘force‘ flag and can
>>> fail
>>>>> to prevent data loss. Ignite and IgniteMXBean are different interfaces.
>>>>> Unfortunately, they have same method
>>>>>
>>>>> void  active(boolean active)
>>>>>
>>>>> When executed as IgniteMXBean it should fail if user can lose data. When
>>>>> executed from code via interface Ignite probably not. To solve this I
>>>>> suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST
>>> and
>>>>> other API.
>>>>>
>>>>> пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <
>>> [hidden email]
>>>>>> :
>>>>>
>>>>>> Igniters,
>>>>>>
>>>>>> Do we really need the confirmation flag on the public API? I absolutely
>>>>>> agree on the CLI and MXBean, but what is the reason for the flag in the
>>>>>> API? It will be specified at the compile time anyway and does not
>>> prevent
>>>>>> any user error.
>>>>>> From the implementation point of view I see no contradiction - we can
>>> add
>>>>>> the new method to the MXBean, but nothing forces us to add it to Ignite
>>>>>> interface - those interfaces are not related.
>>>>>>
>>>>>
>>>
>>>
>

[Steshin Vladimir]

 Vyacheslav,

>>> Let's assume that I have a mixed cluster with persistent cache and
in-memory cache which is backed by 3-rd party persistence. I see no reason
to throw an exception in that case at least.



if you have only persistent caches, no warning/confirmation is supposed at
all.



>>> Is it possible to
add new methods as follows: activateCluster()/deactivateCluster() and
deprecate IgniteMXBean#active(boolean)?



I’m afraid this won’t stop anyone from using old deprecated
IgniteMXBean#active(boolean).
It is quite obvious to execute through JMX despite it is deprecated.

пт, 14 февр. 2020 г. в 17:36, Вячеслав Коптилин <[hidden email]>:

> Hello Nikolay,
>
> > Should public java API continue to silently clear in-memory caches?
> Let's assume that I have a mixed cluster with persistent cache and
> in-memory cache which is backed by 3-rd party persistence. I see no reason
> to throw an exception in that case at least.
> Anyway, this fact should be clearly stated in the Javadoc and documentation
> of course.
>
> > What is your suggestion for the API?
> I think we are talking about JMX methods. Am I correct? Is it possible to
> add new methods as follows: activateCluster()/deactivateCluster() and
> deprecate IgniteMXBean#active(boolean)?
> Does this make sense? Am I missing something?
>
> Thanks,
> S.
>
> пт, 14 февр. 2020 г. в 16:17, Nikolay Izhikov <[hidden email]>:
>
> > Vyacheslav.
> >
> > What is your suggestion for the API?
> >
> > Single implementation for both Ignite#active(boolean) and
> > IgniteMXBean#active(boolean)
> > Should public java API continue to silently clears in-memory caches?
> >
> >
> > > 14 февр. 2020 г., в 15:56, Вячеслав Коптилин <[hidden email]
> >
> > написал(а):
> > >
> > > Hello Vladimir,
> > >
> > >> adding a new method with force flag means old methods change their
> > > behavior:
> > > I don't think that changing the behavior of public API is the right
> way.
> > > Moreover, I agree with Alex that there is no need to introduce a
> > > "confirmation" flag to the java API.
> > >
> > > Thanks,
> > > S.
> > >
> > > пт, 14 февр. 2020 г. в 15:38, Vladimir Steshin <[hidden email]>:
> > >
> > >> Alexey, adding a new method with force flag means old methods change
> > their
> > >> behavior: they are considered as executed without ‘force‘ flag and can
> > fail
> > >> to prevent data loss. Ignite and IgniteMXBean are different
> interfaces.
> > >> Unfortunately, they have same method
> > >>
> > >> void  active(boolean active)
> > >>
> > >> When executed as IgniteMXBean it should fail if user can lose data.
> When
> > >> executed from code via interface Ignite probably not. To solve this I
> > >> suggest to add ‘force’ flag for every deactivation mode: CLI/JMX/REST
> > and
> > >> other API.
> > >>
> > >> пт, 14 февр. 2020 г. в 15:20, Alexey Goncharuk <
> > [hidden email]
> > >>> :
> > >>
> > >>> Igniters,
> > >>>
> > >>> Do we really need the confirmation flag on the public API? I
> absolutely
> > >>> agree on the CLI and MXBean, but what is the reason for the flag in
> the
> > >>> API? It will be specified at the compile time anyway and does not
> > prevent
> > >>> any user error.
> > >>> From the implementation point of view I see no contradiction - we can
> > add
> > >>> the new method to the MXBean, but nothing forces us to add it to
> Ignite
> > >>> interface - those interfaces are not related.
> > >>>
> > >>
> >
> >
>