Data vanished from cluster after INACTIVE/ACTIVE switch

[Nikolay Izhikov-2]

Hello, Igniters.

I found really confusing results of the simple test.
Data from the in-memory cache are vanished after change cluster state to INACTIVE/ACTIVE.

Is this a bug or expected behavior?


```
public class ClusterDeactivateTest extends GridCommonAbstractTest {
    String name = "my-cache";

    /** */
    @Test
    public void testDataPresent() throws Exception {
        IgniteEx i = startGrid(0);

        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!
    }
}
```

[Alexey Goncharuk]

Nikolay,

Inactive state deallocates all possible resources by design, including the
data regions. If data region is not backed by a persistent storage, the
data is lost, this is an expected behavior.

ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov <[hidden email]>:

> Hello, Igniters.
>
> I found really confusing results of the simple test.
> Data from the in-memory cache are vanished after change cluster state to
> INACTIVE/ACTIVE.
>
> Is this a bug or expected behavior?
>
>
> ```
> public class ClusterDeactivateTest extends GridCommonAbstractTest {
>     String name = "my-cache";
>
>     /** */
>     @Test
>     public void testDataPresent() throws Exception {
>         IgniteEx i = startGrid(0);
>
>         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!
>     }
> }
> ```

[Nikolay Izhikov-2]

Hello, Alexey.

Thanks for the feedback.
It seems for me as a very unexpected behavior from the users point of view.

I propose to 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.

What do you think?

> 30 янв. 2020 г., в 12:32, Alexey Goncharuk <[hidden email]> написал(а):
>
> Nikolay,
>
> Inactive state deallocates all possible resources by design, including the
> data regions. If data region is not backed by a persistent storage, the
> data is lost, this is an expected behavior.
>
> ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov <[hidden email]>:
>
>> Hello, Igniters.
>>
>> I found really confusing results of the simple test.
>> Data from the in-memory cache are vanished after change cluster state to
>> INACTIVE/ACTIVE.
>>
>> Is this a bug or expected behavior?
>>
>>
>> ```
>> public class ClusterDeactivateTest extends GridCommonAbstractTest {
>>    String name = "my-cache";
>>
>>    /** */
>>    @Test
>>    public void testDataPresent() throws Exception {
>>        IgniteEx i = startGrid(0);
>>
>>        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!
>>    }
>> }
>> ```

[Alexey Goncharuk]

Nikolay,

This change will affect only the command-line utility, correct? No changes
for the public API are planned?

чт, 30 янв. 2020 г. в 12:46, Nikolay Izhikov <[hidden email]>:

> Hello, Alexey.
>
> Thanks for the feedback.
> It seems for me as a very unexpected behavior from the users point of view.
>
> I propose to 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.
>
> What do you think?
>
>
> > 30 янв. 2020 г., в 12:32, Alexey Goncharuk <[hidden email]>
> написал(а):
> >
> > Nikolay,
> >
> > Inactive state deallocates all possible resources by design, including
> the
> > data regions. If data region is not backed by a persistent storage, the
> > data is lost, this is an expected behavior.
> >
> > ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov <[hidden email]>:
> >
> >> Hello, Igniters.
> >>
> >> I found really confusing results of the simple test.
> >> Data from the in-memory cache are vanished after change cluster state to
> >> INACTIVE/ACTIVE.
> >>
> >> Is this a bug or expected behavior?
> >>
> >>
> >> ```
> >> public class ClusterDeactivateTest extends GridCommonAbstractTest {
> >>    String name = "my-cache";
> >>
> >>    /** */
> >>    @Test
> >>    public void testDataPresent() throws Exception {
> >>        IgniteEx i = startGrid(0);
> >>
> >>        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!
> >>    }
> >> }
> >> ```
>
>

[Nikolay Izhikov-2]

As far as I know we have several places to manage cluster state:

1. Java API - Ignite#cluster#state
2. CLI utility - control.sh
3. JMX beans(can we manage cluster state from JMX?)

I think we should add new parameter to the all management APIs.

What do you think?

> 30 янв. 2020 г., в 12:51, Alexey Goncharuk <[hidden email]> написал(а):
>
> Nikolay,
>
> This change will affect only the command-line utility, correct? No changes
> for the public API are planned?
>
> чт, 30 янв. 2020 г. в 12:46, Nikolay Izhikov <[hidden email]>:
>
>> Hello, Alexey.
>>
>> Thanks for the feedback.
>> It seems for me as a very unexpected behavior from the users point of view.
>>
>> I propose to 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.
>>
>> What do you think?
>>
>>
>>> 30 янв. 2020 г., в 12:32, Alexey Goncharuk <[hidden email]>
>> написал(а):
>>>
>>> Nikolay,
>>>
>>> Inactive state deallocates all possible resources by design, including
>> the
>>> data regions. If data region is not backed by a persistent storage, the
>>> data is lost, this is an expected behavior.
>>>
>>> ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov <[hidden email]>:
>>>
>>>> Hello, Igniters.
>>>>
>>>> I found really confusing results of the simple test.
>>>> Data from the in-memory cache are vanished after change cluster state to
>>>> INACTIVE/ACTIVE.
>>>>
>>>> Is this a bug or expected behavior?
>>>>
>>>>
>>>> ```
>>>> public class ClusterDeactivateTest extends GridCommonAbstractTest {
>>>>   String name = "my-cache";
>>>>
>>>>   /** */
>>>>   @Test
>>>>   public void testDataPresent() throws Exception {
>>>>       IgniteEx i = startGrid(0);
>>>>
>>>>       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!
>>>>   }
>>>> }
>>>> ```
>>
>>

[Alexey Goncharuk]

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.

[dmagda]

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

[Alexey Goncharuk]

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

[Ivan Pavlukhin]

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

[Steshin Vladimir]

Hi folks. I created a ticket for this (IGNITE-12614):



----

Currently, anyone is able to silently deactivate cluster with command line
utility (control.sh). Probably with JMX too. Same for the API: Java API –
Ignite.cluster.state(). That would lead to data loss when the persistence
is off. In-memory data is erased during deactivation. Such behavior can be
considered as unexpected to user.

Suggestions for the CLI/JMX:

1) disallow silent deactivation of cluster keeping caches. Show a warning
like “Your cluster has in-memory cache configured. During deactivation all
data from these caches will be cleared!”

2) Add param ‘--force’ which skips the warning message.

-----

Going to fix the problem if there are no disagreement
<https://www.linguee.com/english-russian/translation/disagreement.html>s

пт, 31 янв. 2020 г. в 13:17, Ivan Pavlukhin <[hidden email]>:

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

[Nikolay Izhikov-2]

Go for it, Vladimir!

> 31 янв. 2020 г., в 16:15, Vladimir Steshin <[hidden email]> написал(а):
>
> Hi folks. I created a ticket for this (IGNITE-12614):
>
>
>
> ----
>
> Currently, anyone is able to silently deactivate cluster with command line
> utility (control.sh). Probably with JMX too. Same for the API: Java API –
> Ignite.cluster.state(). That would lead to data loss when the persistence
> is off. In-memory data is erased during deactivation. Such behavior can be
> considered as unexpected to user.
>
> Suggestions for the CLI/JMX:
>
> 1) disallow silent deactivation of cluster keeping caches. Show a warning
> like “Your cluster has in-memory cache configured. During deactivation all
> data from these caches will be cleared!”
>
> 2) Add param ‘--force’ which skips the warning message.
>
> -----
>
> Going to fix the problem if there are no disagreement
> <https://www.linguee.com/english-russian/translation/disagreement.html>s
>
> пт, 31 янв. 2020 г. в 13:17, Ivan Pavlukhin <[hidden email]>:
>
>> 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
>>

[dmagda]

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
>

[Alexey Goncharuk]

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

[Alexei Scherbakov]

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]

Alexey Goncharuk,

I see no issues with "lost" partitions. The same is possible right now in
persistence mode. Node can be killed and data erased while grid is
deactivated.

After re-join it should rebalance itself from existing owners (if any
exists).

вт, 4 февр. 2020 г. в 10:54, Alexei Scherbakov <[hidden email]
>:

> 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

[dmagda]

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]

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

[dmagda]

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]

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

[dmagda]

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