Data vanished from cluster after INACTIVE/ACTIVE switch

[slava.koptilin]

Hi Vladimir,

> if you have only persistent caches, no warning/confirmation is supposed
at all.
I am talking about MIXED cluster with persistent cache and *in-memory*
cache which is backed by *3-rd party persistence*.

> I’m afraid this won’t stop anyone from using old deprecated
IgniteMXBean#active(boolean)
That is why I do not like to expose such functionality through JMX.

Thanks,
S.

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

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

[Steshin Vladimir]

Vyacheslav,



>>> I am talking about MIXED cluster with persistent cache and *in-memory*
cache which is backed by *3-rd party persistence*.



We do not know what exactly does *3-rd party persistence*. It may store
only specific filtered data, small part of data. I think it is out of
responsibility of the persistence. Such caches might be considered as
in-memory only.



>>> That is why I do not like to expose such functionality through JMX.

But it is exposed also in CLI and REST. Just various call types. Why hide
it from JMX? Or why it is supposed to act differently? If CLI (and REST)
requires forced deactivation, why JMX would act in other way at the same
conditions?

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

> Hi Vladimir,
>
> > if you have only persistent caches, no warning/confirmation is supposed
> at all.
> I am talking about MIXED cluster with persistent cache and *in-memory*
> cache which is backed by *3-rd party persistence*.
>
> > I’m afraid this won’t stop anyone from using old deprecated
> IgniteMXBean#active(boolean)
> That is why I do not like to expose such functionality through JMX.
>
> Thanks,
> S.
>
> пт, 14 февр. 2020 г. в 18:02, Vladimir Steshin <[hidden email]>:
>
> >  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.
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
> >
>

[slava.koptilin]

Hello Vladimir,

> We do not know what exactly does *3-rd party persistence*.
From my point of view, this is clearly stated here
https://www.jcp.org/en/jsr/detail?id=107 |
https://github.com/jsr107/jsr107spec and here
https://apacheignite.readme.io/docs/3rd-party-store.
In general, it is a caching layer above an existing 3rd party database.
That is all.

> Such caches might be considered as in-memory only.
I don't think so. It does not really matter which persistence is used
(Ignite native persistence or RDBMS).

I would like to highlight the following: In my humble opinion, until we
have a consensus that the existing behavior is a bug (and that is the
question for now) we should not change it.
As mentioned by Alex G: "Inactive state deallocates all possible resources
by design, including the data regions." Perhaps, this is not a good
approach, but...

Thanks,
Slava.

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

> Vyacheslav,
>
>
>
> >>> I am talking about MIXED cluster with persistent cache and *in-memory*
> cache which is backed by *3-rd party persistence*.
>
>
>
> We do not know what exactly does *3-rd party persistence*. It may store
> only specific filtered data, small part of data. I think it is out of
> responsibility of the persistence. Such caches might be considered as
> in-memory only.
>
>
>
> >>> That is why I do not like to expose such functionality through JMX.
>
> But it is exposed also in CLI and REST. Just various call types. Why hide
> it from JMX? Or why it is supposed to act differently? If CLI (and REST)
> requires forced deactivation, why JMX would act in other way at the same
> conditions?
>
> пт, 14 февр. 2020 г. в 18:40, Вячеслав Коптилин <[hidden email]
> >:
>
> > Hi Vladimir,
> >
> > > if you have only persistent caches, no warning/confirmation is supposed
> > at all.
> > I am talking about MIXED cluster with persistent cache and *in-memory*
> > cache which is backed by *3-rd party persistence*.
> >
> > > I’m afraid this won’t stop anyone from using old deprecated
> > IgniteMXBean#active(boolean)
> > That is why I do not like to expose such functionality through JMX.
> >
> > Thanks,
> > S.
> >
> > пт, 14 февр. 2020 г. в 18:02, Vladimir Steshin <[hidden email]>:
> >
> > >  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.
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

[Nikolay Izhikov-2]

Hello, Vyacheslav.

> In my humble opinion, until we have a consensus that the existing behavior is a bug (and that is the question for now)


I think we have consensus that current behavior is *NOT A BUG*.
It is a design choice.

But, we have consensus that consequences of this choice is not transparent to the end-user.
So we have:

1. Explicitly warn user about consequences of the deactivation.
2. Require additional confirmation.

> 17 февр. 2020 г., в 12:38, Вячеслав Коптилин <[hidden email]> написал(а):
>
> Hello Vladimir,
>
>> We do not know what exactly does *3-rd party persistence*.
> From my point of view, this is clearly stated here
> https://www.jcp.org/en/jsr/detail?id=107 |
> https://github.com/jsr107/jsr107spec and here
> https://apacheignite.readme.io/docs/3rd-party-store.
> In general, it is a caching layer above an existing 3rd party database.
> That is all.
>
>> Such caches might be considered as in-memory only.
> I don't think so. It does not really matter which persistence is used
> (Ignite native persistence or RDBMS).
>
> I would like to highlight the following: In my humble opinion, until we
> have a consensus that the existing behavior is a bug (and that is the
> question for now) we should not change it.
> As mentioned by Alex G: "Inactive state deallocates all possible resources
> by design, including the data regions." Perhaps, this is not a good
> approach, but...
>
> Thanks,
> Slava.
>
> пт, 14 февр. 2020 г. в 18:56, Vladimir Steshin <[hidden email]>:
>
>> Vyacheslav,
>>
>>
>>
>>>>> I am talking about MIXED cluster with persistent cache and *in-memory*
>> cache which is backed by *3-rd party persistence*.
>>
>>
>>
>> We do not know what exactly does *3-rd party persistence*. It may store
>> only specific filtered data, small part of data. I think it is out of
>> responsibility of the persistence. Such caches might be considered as
>> in-memory only.
>>
>>
>>
>>>>> That is why I do not like to expose such functionality through JMX.
>>
>> But it is exposed also in CLI and REST. Just various call types. Why hide
>> it from JMX? Or why it is supposed to act differently? If CLI (and REST)
>> requires forced deactivation, why JMX would act in other way at the same
>> conditions?
>>
>> пт, 14 февр. 2020 г. в 18:40, Вячеслав Коптилин <[hidden email]
>>> :
>>
>>> Hi Vladimir,
>>>
>>>> if you have only persistent caches, no warning/confirmation is supposed
>>> at all.
>>> I am talking about MIXED cluster with persistent cache and *in-memory*
>>> cache which is backed by *3-rd party persistence*.
>>>
>>>> I’m afraid this won’t stop anyone from using old deprecated
>>> IgniteMXBean#active(boolean)
>>> That is why I do not like to expose such functionality through JMX.
>>>
>>> Thanks,
>>> S.
>>>
>>> пт, 14 февр. 2020 г. в 18:02, Vladimir Steshin <[hidden email]>:
>>>
>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

[slava.koptilin]

Hi Nikolay,

> 1. Explicitly warn user about consequences of the deactivation.
I absolutely agree it must be mentioned in the Javadoc, documentation, and
etc.

> Require additional confirmation.
it does make sense to me (control utility and jmx) To be honest, I don't
see a reason to introduce this flag into Java API.

Thanks,
Slava.


пн, 17 февр. 2020 г. в 12:57, Nikolay Izhikov <[hidden email]>:

> Hello, Vyacheslav.
>
> > In my humble opinion, until we have a consensus that the existing
> behavior is a bug (and that is the question for now)
>
>
> I think we have consensus that current behavior is *NOT A BUG*.
> It is a design choice.
>
> But, we have consensus that consequences of this choice is not transparent
> to the end-user.
> So we have:
>
> 1. Explicitly warn user about consequences of the deactivation.
> 2. Require additional confirmation.
>
>
>
> > 17 февр. 2020 г., в 12:38, Вячеслав Коптилин <[hidden email]>
> написал(а):
> >
> > Hello Vladimir,
> >
> >> We do not know what exactly does *3-rd party persistence*.
> > From my point of view, this is clearly stated here
> > https://www.jcp.org/en/jsr/detail?id=107 |
> > https://github.com/jsr107/jsr107spec and here
> > https://apacheignite.readme.io/docs/3rd-party-store.
> > In general, it is a caching layer above an existing 3rd party database.
> > That is all.
> >
> >> Such caches might be considered as in-memory only.
> > I don't think so. It does not really matter which persistence is used
> > (Ignite native persistence or RDBMS).
> >
> > I would like to highlight the following: In my humble opinion, until we
> > have a consensus that the existing behavior is a bug (and that is the
> > question for now) we should not change it.
> > As mentioned by Alex G: "Inactive state deallocates all possible
> resources
> > by design, including the data regions." Perhaps, this is not a good
> > approach, but...
> >
> > Thanks,
> > Slava.
> >
> > пт, 14 февр. 2020 г. в 18:56, Vladimir Steshin <[hidden email]>:
> >
> >> Vyacheslav,
> >>
> >>
> >>
> >>>>> I am talking about MIXED cluster with persistent cache and
> *in-memory*
> >> cache which is backed by *3-rd party persistence*.
> >>
> >>
> >>
> >> We do not know what exactly does *3-rd party persistence*. It may store
> >> only specific filtered data, small part of data. I think it is out of
> >> responsibility of the persistence. Such caches might be considered as
> >> in-memory only.
> >>
> >>
> >>
> >>>>> That is why I do not like to expose such functionality through JMX.
> >>
> >> But it is exposed also in CLI and REST. Just various call types. Why
> hide
> >> it from JMX? Or why it is supposed to act differently? If CLI (and REST)
> >> requires forced deactivation, why JMX would act in other way at the same
> >> conditions?
> >>
> >> пт, 14 февр. 2020 г. в 18:40, Вячеслав Коптилин <
> [hidden email]
> >>> :
> >>
> >>> Hi Vladimir,
> >>>
> >>>> if you have only persistent caches, no warning/confirmation is
> supposed
> >>> at all.
> >>> I am talking about MIXED cluster with persistent cache and *in-memory*
> >>> cache which is backed by *3-rd party persistence*.
> >>>
> >>>> I’m afraid this won’t stop anyone from using old deprecated
> >>> IgniteMXBean#active(boolean)
> >>> That is why I do not like to expose such functionality through JMX.
> >>>
> >>> Thanks,
> >>> S.
> >>>
> >>> пт, 14 февр. 2020 г. в 18:02, Vladimir Steshin <[hidden email]>:
> >>>
> >>>> 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.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>

[Steshin Vladimir]

>
> Hi,  Vyacheslav.
>
>
>
> >>> In general, it is a caching layer above an existing 3rd party database.
> That is all.
> >>> I don't think so. It does not really matter which persistence is used
> (Ignite native persistence or RDBMS).
>
>
>
> Ok. I think we might also check if read/write-through is enabled for a
> cache to consider it as persistent and not to warn user, not to require
> ‘force’ flag.
>
>
>
>
>
> >>> it does make sense to me (control utility and jmx) To be honest, I
> don't
> see a reason to introduce this flag into Java API.
>
>
>
> The only reason is the same implementation IgniteMXBean#active(boolean)
> and Ignite#active(boolean). Looks like we have to choose whether to allow
> user erase data unexpectedly or to change behavior of the API call.
>

[Alexey Goncharuk]

пн, 17 февр. 2020 г. в 14:18, Vladimir Steshin <[hidden email]>:

> > The only reason is the same implementation IgniteMXBean#active(boolean)
> > and Ignite#active(boolean). Looks like we have to choose whether to allow
> > user erase data unexpectedly or to change behavior of the API call.
>

Vladimir, those two interfaces (IgniteMXBean and Ignite) are decoupled and
must not share the same implementation. Internally, we can route the
methods to separate implementations. Or am I missing something?

For me the analogy is pretty simple - we do have to specify an additional
flag for 'rm' command, but we do not have any confirmation flags for
syscalls.

--AG

[Steshin Vladimir]

Alexey, as I mentioned, at now we have same implementation for IgniteMXBean
and Ignite in IgniteKernal. Already is. I agree, the implementations should
be decoupled. But extracting IgniteMXBean from IgniteKernal seems too bulky
solution to me. Tacking in account lot of variants of deactivation methods
(many deprecated) and invocation points I propose to bring single
centralized solution.

пн, 17 февр. 2020 г. в 16:59, Alexey Goncharuk <[hidden email]>:

> пн, 17 февр. 2020 г. в 14:18, Vladimir Steshin <[hidden email]>:
>
> > > The only reason is the same implementation IgniteMXBean#active(boolean)
> > > and Ignite#active(boolean). Looks like we have to choose whether to
> allow
> > > user erase data unexpectedly or to change behavior of the API call.
> >
>
> Vladimir, those two interfaces (IgniteMXBean and Ignite) are decoupled and
> must not share the same implementation. Internally, we can route the
> methods to separate implementations. Or am I missing something?
>
> For me the analogy is pretty simple - we do have to specify an additional
> flag for 'rm' command, but we do not have any confirmation flags for
> syscalls.
>
> --AG
>

[Alexey Goncharuk]

I do not think the change size can even be an argument for not doing a
proper improvement. We need to agree whether IgniteMxBean#active(boolean)
and Ignite#active(boolean) behaving differently is ok from the user side.

[Nikolay Izhikov-2]

Hello, Alexey.

> We need to agree whether IgniteMxBean#active(boolean) and Ignite#active(boolean) behaving differently is ok from the user side.

I think it’s not OK.

We should provide consistent behavior for all management APIs: jmx, control.sh, REST, Java API.
The primary use-case I keep in mind - third party management console written in java.
It will use Java API and should have an ability to execute «safe»(without data vanish) and «unsafe» deactivation.


> 18 февр. 2020 г., в 12:28, Alexey Goncharuk <[hidden email]> написал(а):
>
> I do not think the change size can even be an argument for not doing a
> proper improvement. We need to agree whether IgniteMxBean#active(boolean)
> and Ignite#active(boolean) behaving differently is ok from the user side.

[Steshin Vladimir]

Hi, Igniters.

I've found other deactivation issue. Should we consider this behavior as
a bug?

IgniteEx ignite = startGrids(3);

         IgniteAtomicLong atomicLong = ignite.atomicLong("atomic", 10L,
true);


         IgniteLock lock = ignite.reentrantLock("lock", true, false, true);


         lock.lock();

         assertEquals(10L, atomicLong.get());
         assertTrue(lock.isLocked());

         lock.unlock();

         ignite.active(false);
         ignite.active(true);

         // Failed: java.lang.NullPointerException at
GridCacheLockImpl.java:496
         assertFalse(lock.isLocked());

         // Failrd: org.apache.ignite.IgniteException: Failed to find
atomic long: testAtomic
         assertEquals(10L, atomicLong.get());

[Steshin Vladimir]

     Hi, all.

Fixes for control.sh and the REST have been merged. Could anyone take a
look to the previous email with an issue? Isn't this conductvery wierd?

[Nikolay Izhikov-2]

Hello, Vladimir.

If there is at lease one persistent data region then system data region also becomes persistent.
Your example applies only to pure in-memory clusters.

And should be covered with the —force parameter we added.

What do you think?

> 17 марта 2020 г., в 13:45, Vladimir Steshin <[hidden email]> написал(а):
>
>     Hi, all.
>
> Fixes for control.sh and the REST have been merged. Could anyone take a look to the previous email with an issue? Isn't this conductvery wierd?
>

[Steshin Vladimir]

Nikolay, hi.

>>> And should be covered with the  —force parameter we added.

As fix for user cases - yes. My idea is to emphasize overall ability to
lose various objects, not only data. Probably might be reconsidered in
future.


17.03.2020 13:49, Nikolay Izhikov пишет:

> Hello, Vladimir.
>
> If there is at lease one persistent data region then system data region also becomes persistent.
> Your example applies only to pure in-memory clusters.
>
> And should be covered with the —force parameter we added.
>
> What do you think?
>
>> 17 марта 2020 г., в 13:45, Vladimir Steshin <[hidden email]> написал(а):
>>
>>      Hi, all.
>>
>> Fixes for control.sh and the REST have been merged. Could anyone take a look to the previous email with an issue? Isn't this conductvery wierd?
>>

[Nikolay Izhikov-2]

Hello, Vladimir.

I don’t get it.

What is your proposal?
What we should do?

> 17 марта 2020 г., в 14:11, Vladimir Steshin <[hidden email]> написал(а):
>
> Nikolay, hi.
>
>>>> And should be covered with the  —force parameter we added.
>
> As fix for user cases - yes. My idea is to emphasize overall ability to lose various objects, not only data. Probably might be reconsidered in future.
>
>
> 17.03.2020 13:49, Nikolay Izhikov пишет:
>> Hello, Vladimir.
>>
>> If there is at lease one persistent data region then system data region also becomes persistent.
>> Your example applies only to pure in-memory clusters.
>>
>> And should be covered with the —force parameter we added.
>>
>> What do you think?
>>
>>> 17 марта 2020 г., в 13:45, Vladimir Steshin <[hidden email]> написал(а):
>>>
>>>     Hi, all.
>>>
>>> Fixes for control.sh and the REST have been merged. Could anyone take a look to the previous email with an issue? Isn't this conductvery wierd?
>>>

[Steshin Vladimir]

Nikolay, I think we should reconsider clearing at least system caches
when deactivating.

17.03.2020 14:18, Nikolay Izhikov пишет:

> Hello, Vladimir.
>
> I don’t get it.
>
> What is your proposal?
> What we should do?
>
>> 17 марта 2020 г., в 14:11, Vladimir Steshin <[hidden email]> написал(а):
>>
>> Nikolay, hi.
>>
>>>>> And should be covered with the  —force parameter we added.
>> As fix for user cases - yes. My idea is to emphasize overall ability to lose various objects, not only data. Probably might be reconsidered in future.
>>
>>
>> 17.03.2020 13:49, Nikolay Izhikov пишет:
>>> Hello, Vladimir.
>>>
>>> If there is at lease one persistent data region then system data region also becomes persistent.
>>> Your example applies only to pure in-memory clusters.
>>>
>>> And should be covered with the —force parameter we added.
>>>
>>> What do you think?
>>>
>>>> 17 марта 2020 г., в 13:45, Vladimir Steshin <[hidden email]> написал(а):
>>>>
>>>>      Hi, all.
>>>>
>>>> Fixes for control.sh and the REST have been merged. Could anyone take a look to the previous email with an issue? Isn't this conductvery wierd?
>>>>

[Ivan Rakov]

Folks,

Let's revive this discussion until it's too late and all API changes are
merged to master [1].
Seems like we don't have a final agreement on whether we should add force
flag to deactivation API.

First of all, I think we are all on the same page that in-memory caches
data vanishing on deactivation is counter-intuitive and dangerous. As a
final solution, I'd want to see behavior when all in-memory data is
available after deactivation and further activation. I believe it's
possible to don't deallocate memory (like mentioned before, we already can
achieve that with IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully
reuse all loaded data pages on next activation and caches start.

Also, this is a wider question, but: do we understand what cluster
deactivation is actually intended for? I can only think of two cases:
- graceful cluster shutdown: an ability to cut checkpoints and to end
transactional load consistently prior to further stop of all nodes
- blocking all API (both reads and writes) due to some maintenance
Neither of them requires forcefully clearing all in-memory data on
deactivation. If everyone agrees, from now on we should assume data
clearing as system design flaw that should be fixed, not as possible
scenario which we should support on the API level.

Considering this, do we really need to introduce force flag as a temporary
precaution? I have at least two reasons against it:
1) Once API was changed and released, we have to support it until the next
major release. If we all understand that data vanishing issue is fixable, I
believe we shouldn't engrave in the API flags that will become pointless.
2) More personal one, but I'm against any force flags in the API. This
makes API harder to understand; more than that, the presence of such flags
just highlights that API is poorly designed.

I suggest to rollback [2] from AI master, stop working on [1] and focus on
how to implement keeping in-memory data after the deactivation.
I think we can still require user consent for deactivation via control.sh
(it already requires --yes) and JMX.

Thoughts?

[1]: https://issues.apache.org/jira/browse/IGNITE-12614
[2]: https://issues.apache.org/jira/browse/IGNITE-12701

--
Ivan


On Tue, Mar 17, 2020 at 2:26 PM Vladimir Steshin <[hidden email]> wrote:

> Nikolay, I think we should reconsider clearing at least system caches
> when deactivating.
>
> 17.03.2020 14:18, Nikolay Izhikov пишет:
> > Hello, Vladimir.
> >
> > I don’t get it.
> >
> > What is your proposal?
> > What we should do?
> >
> >> 17 марта 2020 г., в 14:11, Vladimir Steshin <[hidden email]>
> написал(а):
> >>
> >> Nikolay, hi.
> >>
> >>>>> And should be covered with the  —force parameter we added.
> >> As fix for user cases - yes. My idea is to emphasize overall ability to
> lose various objects, not only data. Probably might be reconsidered in
> future.
> >>
> >>
> >> 17.03.2020 13:49, Nikolay Izhikov пишет:
> >>> Hello, Vladimir.
> >>>
> >>> If there is at lease one persistent data region then system data
> region also becomes persistent.
> >>> Your example applies only to pure in-memory clusters.
> >>>
> >>> And should be covered with the —force parameter we added.
> >>>
> >>> What do you think?
> >>>
> >>>> 17 марта 2020 г., в 13:45, Vladimir Steshin <[hidden email]>
> написал(а):
> >>>>
> >>>>      Hi, all.
> >>>>
> >>>> Fixes for control.sh and the REST have been merged. Could anyone take
> a look to the previous email with an issue? Isn't this conductvery wierd?
> >>>>
>

[Nikolay Izhikov-2]

Hello, Ivan.

> Seems like we don't have a final agreement on whether we should add force
flag to deactivation API.

I think the only question is - Do we need —force flag in Java API or not.


> As a final solution, I'd want to see behavior when all in-memory data is available after deactivation and further activation.

Agree.

> I believe it’s possible to don't deallocate memory
> (like mentioned before, we already can achieve that with IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully reuse all loaded data pages on next activation and caches start.

As far as I know, IGNITE_REUSE_MEMORY_ON_DEACTIVATE is for *other* purpose.
Can you provide a simple reproducer when in-memory data not cleared on deactivation?

> Considering this, do we really need to introduce force flag as a temporary precaution?

My answer is yes we need it.
Right now, we can’t prevent data loss on deactivation for in-memory caches.

For me, the ultimate value of Ignite into real production environment is user data.
If we have some cases when data is lost - we should avoid it as hard as we can.

So, for now, this flag required.

> I suggest to rollback [2] from AI master, stop working on [1] and focus on how to implement keeping in-memory data after the deactivation.

I think we can remove —force flag only after implementation of keeping in-memory data on deactivation would be finished.
If that happens before 2.9 then we can have clearer API.

> 23 марта 2020 г., в 18:47, Ivan Rakov <[hidden email]> написал(а):
>
> Folks,
>
> Let's revive this discussion until it's too late and all API changes are
> merged to master [1].
> Seems like we don't have a final agreement on whether we should add force
> flag to deactivation API.
>
> First of all, I think we are all on the same page that in-memory caches
> data vanishing on deactivation is counter-intuitive and dangerous. As a
> final solution, I'd want to see behavior when all in-memory data is
> available after deactivation and further activation. I believe it's
> possible to don't deallocate memory (like mentioned before, we already can
> achieve that with IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully
> reuse all loaded data pages on next activation and caches start.
>
> Also, this is a wider question, but: do we understand what cluster
> deactivation is actually intended for? I can only think of two cases:
> - graceful cluster shutdown: an ability to cut checkpoints and to end
> transactional load consistently prior to further stop of all nodes
> - blocking all API (both reads and writes) due to some maintenance
> Neither of them requires forcefully clearing all in-memory data on
> deactivation. If everyone agrees, from now on we should assume data
> clearing as system design flaw that should be fixed, not as possible
> scenario which we should support on the API level.
>
> Considering this, do we really need to introduce force flag as a temporary
> precaution? I have at least two reasons against it:
> 1) Once API was changed and released, we have to support it until the next
> major release. If we all understand that data vanishing issue is fixable, I
> believe we shouldn't engrave in the API flags that will become pointless.
> 2) More personal one, but I'm against any force flags in the API. This
> makes API harder to understand; more than that, the presence of such flags
> just highlights that API is poorly designed.
>
> I suggest to rollback [2] from AI master, stop working on [1] and focus on
> how to implement keeping in-memory data after the deactivation.
> I think we can still require user consent for deactivation via control.sh
> (it already requires --yes) and JMX.
>
> Thoughts?
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-12614
> [2]: https://issues.apache.org/jira/browse/IGNITE-12701
>
> --
> Ivan
>
>
> On Tue, Mar 17, 2020 at 2:26 PM Vladimir Steshin <[hidden email]> wrote:
>
>> Nikolay, I think we should reconsider clearing at least system caches
>> when deactivating.
>>
>> 17.03.2020 14:18, Nikolay Izhikov пишет:
>>> Hello, Vladimir.
>>>
>>> I don’t get it.
>>>
>>> What is your proposal?
>>> What we should do?
>>>
>>>> 17 марта 2020 г., в 14:11, Vladimir Steshin <[hidden email]>
>> написал(а):
>>>>
>>>> Nikolay, hi.
>>>>
>>>>>>> And should be covered with the  —force parameter we added.
>>>> As fix for user cases - yes. My idea is to emphasize overall ability to
>> lose various objects, not only data. Probably might be reconsidered in
>> future.
>>>>
>>>>
>>>> 17.03.2020 13:49, Nikolay Izhikov пишет:
>>>>> Hello, Vladimir.
>>>>>
>>>>> If there is at lease one persistent data region then system data
>> region also becomes persistent.
>>>>> Your example applies only to pure in-memory clusters.
>>>>>
>>>>> And should be covered with the —force parameter we added.
>>>>>
>>>>> What do you think?
>>>>>
>>>>>> 17 марта 2020 г., в 13:45, Vladimir Steshin <[hidden email]>
>> написал(а):
>>>>>>
>>>>>>     Hi, all.
>>>>>>
>>>>>> Fixes for control.sh and the REST have been merged. Could anyone take
>> a look to the previous email with an issue? Isn't this conductvery wierd?
>>>>>>
>>

[Alexei Scherbakov]

Nikolay,

I'm on the same page with Ivan.

Having "force" flag in public API as preposterous as having it in
System.exit.
For me it looks like badly designed API.
If a call to some method is dangerous it should be clearly specified in the
javadoc.
I'm also against some "temporary" API.

We should:

1. Partially remove IGNITE-12701 except javadoc part. Note control.sh for a
long time has support for a confirmation on deactivation (interactive mode).
2. IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true already preserves memory content
after deactivation. We should start working on restoring page memory state
after subsequent reactivation.
3. Describe current behavior for in-memory cache on deactivation in Ignite
documentation.


пн, 23 мар. 2020 г. в 21:22, Nikolay Izhikov <[hidden email]>:

> Hello, Ivan.
>
> > Seems like we don't have a final agreement on whether we should add force
> flag to deactivation API.
>
> I think the only question is - Do we need —force flag in Java API or not.
>
>
> > As a final solution, I'd want to see behavior when all in-memory data is
> available after deactivation and further activation.
>
> Agree.
>
> > I believe it’s possible to don't deallocate memory
> > (like mentioned before, we already can achieve that with
> IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully reuse all loaded data
> pages on next activation and caches start.
>
> As far as I know, IGNITE_REUSE_MEMORY_ON_DEACTIVATE is for *other* purpose.
> Can you provide a simple reproducer when in-memory data not cleared on
> deactivation?
>
> > Considering this, do we really need to introduce force flag as a
> temporary precaution?
>
> My answer is yes we need it.
> Right now, we can’t prevent data loss on deactivation for in-memory caches.
>
> For me, the ultimate value of Ignite into real production environment is
> user data.
> If we have some cases when data is lost - we should avoid it as hard as we
> can.
>
> So, for now, this flag required.
>
> > I suggest to rollback [2] from AI master, stop working on [1] and focus
> on how to implement keeping in-memory data after the deactivation.
>
> I think we can remove —force flag only after implementation of keeping
> in-memory data on deactivation would be finished.
> If that happens before 2.9 then we can have clearer API.
>
> > 23 марта 2020 г., в 18:47, Ivan Rakov <[hidden email]>
> написал(а):
> >
> > Folks,
> >
> > Let's revive this discussion until it's too late and all API changes are
> > merged to master [1].
> > Seems like we don't have a final agreement on whether we should add force
> > flag to deactivation API.
> >
> > First of all, I think we are all on the same page that in-memory caches
> > data vanishing on deactivation is counter-intuitive and dangerous. As a
> > final solution, I'd want to see behavior when all in-memory data is
> > available after deactivation and further activation. I believe it's
> > possible to don't deallocate memory (like mentioned before, we already
> can
> > achieve that with IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully
> > reuse all loaded data pages on next activation and caches start.
> >
> > Also, this is a wider question, but: do we understand what cluster
> > deactivation is actually intended for? I can only think of two cases:
> > - graceful cluster shutdown: an ability to cut checkpoints and to end
> > transactional load consistently prior to further stop of all nodes
> > - blocking all API (both reads and writes) due to some maintenance
> > Neither of them requires forcefully clearing all in-memory data on
> > deactivation. If everyone agrees, from now on we should assume data
> > clearing as system design flaw that should be fixed, not as possible
> > scenario which we should support on the API level.
> >
> > Considering this, do we really need to introduce force flag as a
> temporary
> > precaution? I have at least two reasons against it:
> > 1) Once API was changed and released, we have to support it until the
> next
> > major release. If we all understand that data vanishing issue is
> fixable, I
> > believe we shouldn't engrave in the API flags that will become pointless.
> > 2) More personal one, but I'm against any force flags in the API. This
> > makes API harder to understand; more than that, the presence of such
> flags
> > just highlights that API is poorly designed.
> >
> > I suggest to rollback [2] from AI master, stop working on [1] and focus
> on
> > how to implement keeping in-memory data after the deactivation.
> > I think we can still require user consent for deactivation via control.sh
> > (it already requires --yes) and JMX.
> >
> > Thoughts?
> >
> > [1]: https://issues.apache.org/jira/browse/IGNITE-12614
> > [2]: https://issues.apache.org/jira/browse/IGNITE-12701
> >
> > --
> > Ivan
> >
> >
> > On Tue, Mar 17, 2020 at 2:26 PM Vladimir Steshin <[hidden email]>
> wrote:
> >
> >> Nikolay, I think we should reconsider clearing at least system caches
> >> when deactivating.
> >>
> >> 17.03.2020 14:18, Nikolay Izhikov пишет:
> >>> Hello, Vladimir.
> >>>
> >>> I don’t get it.
> >>>
> >>> What is your proposal?
> >>> What we should do?
> >>>
> >>>> 17 марта 2020 г., в 14:11, Vladimir Steshin <[hidden email]>
> >> написал(а):
> >>>>
> >>>> Nikolay, hi.
> >>>>
> >>>>>>> And should be covered with the  —force parameter we added.
> >>>> As fix for user cases - yes. My idea is to emphasize overall ability
> to
> >> lose various objects, not only data. Probably might be reconsidered in
> >> future.
> >>>>
> >>>>
> >>>> 17.03.2020 13:49, Nikolay Izhikov пишет:
> >>>>> Hello, Vladimir.
> >>>>>
> >>>>> If there is at lease one persistent data region then system data
> >> region also becomes persistent.
> >>>>> Your example applies only to pure in-memory clusters.
> >>>>>
> >>>>> And should be covered with the —force parameter we added.
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>>> 17 марта 2020 г., в 13:45, Vladimir Steshin <[hidden email]>
> >> написал(а):
> >>>>>>
> >>>>>>     Hi, all.
> >>>>>>
> >>>>>> Fixes for control.sh and the REST have been merged. Could anyone
> take
> >> a look to the previous email with an issue? Isn't this conductvery
> wierd?
> >>>>>>
> >>
>
>

--

Best regards,
Alexei Scherbakov

[Nikolay Izhikov-2]

Alexey.

Having the way to silently vanish user data is even worse.
So I’m strictly against removing —force flag.

> 24 марта 2020 г., в 10:16, Alexei Scherbakov <[hidden email]> написал(а):
>
> Nikolay,
>
> I'm on the same page with Ivan.
>
> Having "force" flag in public API as preposterous as having it in
> System.exit.
> For me it looks like badly designed API.
> If a call to some method is dangerous it should be clearly specified in the
> javadoc.
> I'm also against some "temporary" API.
>
> We should:
>
> 1. Partially remove IGNITE-12701 except javadoc part. Note control.sh for a
> long time has support for a confirmation on deactivation (interactive mode).
> 2. IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true already preserves memory content
> after deactivation. We should start working on restoring page memory state
> after subsequent reactivation.
> 3. Describe current behavior for in-memory cache on deactivation in Ignite
> documentation.
>
>
> пн, 23 мар. 2020 г. в 21:22, Nikolay Izhikov <[hidden email]>:
>
>> Hello, Ivan.
>>
>>> Seems like we don't have a final agreement on whether we should add force
>> flag to deactivation API.
>>
>> I think the only question is - Do we need —force flag in Java API or not.
>>
>>
>>> As a final solution, I'd want to see behavior when all in-memory data is
>> available after deactivation and further activation.
>>
>> Agree.
>>
>>> I believe it’s possible to don't deallocate memory
>>> (like mentioned before, we already can achieve that with
>> IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully reuse all loaded data
>> pages on next activation and caches start.
>>
>> As far as I know, IGNITE_REUSE_MEMORY_ON_DEACTIVATE is for *other* purpose.
>> Can you provide a simple reproducer when in-memory data not cleared on
>> deactivation?
>>
>>> Considering this, do we really need to introduce force flag as a
>> temporary precaution?
>>
>> My answer is yes we need it.
>> Right now, we can’t prevent data loss on deactivation for in-memory caches.
>>
>> For me, the ultimate value of Ignite into real production environment is
>> user data.
>> If we have some cases when data is lost - we should avoid it as hard as we
>> can.
>>
>> So, for now, this flag required.
>>
>>> I suggest to rollback [2] from AI master, stop working on [1] and focus
>> on how to implement keeping in-memory data after the deactivation.
>>
>> I think we can remove —force flag only after implementation of keeping
>> in-memory data on deactivation would be finished.
>> If that happens before 2.9 then we can have clearer API.
>>
>>> 23 марта 2020 г., в 18:47, Ivan Rakov <[hidden email]>
>> написал(а):
>>>
>>> Folks,
>>>
>>> Let's revive this discussion until it's too late and all API changes are
>>> merged to master [1].
>>> Seems like we don't have a final agreement on whether we should add force
>>> flag to deactivation API.
>>>
>>> First of all, I think we are all on the same page that in-memory caches
>>> data vanishing on deactivation is counter-intuitive and dangerous. As a
>>> final solution, I'd want to see behavior when all in-memory data is
>>> available after deactivation and further activation. I believe it's
>>> possible to don't deallocate memory (like mentioned before, we already
>> can
>>> achieve that with IGNITE_REUSE_MEMORY_ON_DEACTIVATE=true) and carefully
>>> reuse all loaded data pages on next activation and caches start.
>>>
>>> Also, this is a wider question, but: do we understand what cluster
>>> deactivation is actually intended for? I can only think of two cases:
>>> - graceful cluster shutdown: an ability to cut checkpoints and to end
>>> transactional load consistently prior to further stop of all nodes
>>> - blocking all API (both reads and writes) due to some maintenance
>>> Neither of them requires forcefully clearing all in-memory data on
>>> deactivation. If everyone agrees, from now on we should assume data
>>> clearing as system design flaw that should be fixed, not as possible
>>> scenario which we should support on the API level.
>>>
>>> Considering this, do we really need to introduce force flag as a
>> temporary
>>> precaution? I have at least two reasons against it:
>>> 1) Once API was changed and released, we have to support it until the
>> next
>>> major release. If we all understand that data vanishing issue is
>> fixable, I
>>> believe we shouldn't engrave in the API flags that will become pointless.
>>> 2) More personal one, but I'm against any force flags in the API. This
>>> makes API harder to understand; more than that, the presence of such
>> flags
>>> just highlights that API is poorly designed.
>>>
>>> I suggest to rollback [2] from AI master, stop working on [1] and focus
>> on
>>> how to implement keeping in-memory data after the deactivation.
>>> I think we can still require user consent for deactivation via control.sh
>>> (it already requires --yes) and JMX.
>>>
>>> Thoughts?
>>>
>>> [1]: https://issues.apache.org/jira/browse/IGNITE-12614
>>> [2]: https://issues.apache.org/jira/browse/IGNITE-12701
>>>
>>> --
>>> Ivan
>>>
>>>
>>> On Tue, Mar 17, 2020 at 2:26 PM Vladimir Steshin <[hidden email]>
>> wrote:
>>>
>>>> Nikolay, I think we should reconsider clearing at least system caches
>>>> when deactivating.
>>>>
>>>> 17.03.2020 14:18, Nikolay Izhikov пишет:
>>>>> Hello, Vladimir.
>>>>>
>>>>> I don’t get it.
>>>>>
>>>>> What is your proposal?
>>>>> What we should do?
>>>>>
>>>>>> 17 марта 2020 г., в 14:11, Vladimir Steshin <[hidden email]>
>>>> написал(а):
>>>>>>
>>>>>> Nikolay, hi.
>>>>>>
>>>>>>>>> And should be covered with the  —force parameter we added.
>>>>>> As fix for user cases - yes. My idea is to emphasize overall ability
>> to
>>>> lose various objects, not only data. Probably might be reconsidered in
>>>> future.
>>>>>>
>>>>>>
>>>>>> 17.03.2020 13:49, Nikolay Izhikov пишет:
>>>>>>> Hello, Vladimir.
>>>>>>>
>>>>>>> If there is at lease one persistent data region then system data
>>>> region also becomes persistent.
>>>>>>> Your example applies only to pure in-memory clusters.
>>>>>>>
>>>>>>> And should be covered with the —force parameter we added.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>>> 17 марта 2020 г., в 13:45, Vladimir Steshin <[hidden email]>
>>>> написал(а):
>>>>>>>>
>>>>>>>>    Hi, all.
>>>>>>>>
>>>>>>>> Fixes for control.sh and the REST have been merged. Could anyone
>> take
>>>> a look to the previous email with an issue? Isn't this conductvery
>> wierd?
>>>>>>>>
>>>>
>>
>>
>
> --
>
> Best regards,
> Alexei Scherbakov