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, Вячеслав Коптилин <slava.kopti...@gmail.com>: > 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 <vlads...@gmail.com>: > > > 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, Вячеслав Коптилин < > slava.kopti...@gmail.com > > >: > > > > > 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 <nizhi...@apache.org>: > > > > > > > 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, Вячеслав Коптилин < > > slava.kopti...@gmail.com > > > > > > > > написал(а): > > > > > > > > > > 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 <vlads...@gmail.com > >: > > > > > > > > > >> 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 < > > > > alexey.goncha...@gmail.com > > > > >>> : > > > > >> > > > > >>> 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. > > > > >>> > > > > >> > > > > > > > > > > > > > >
