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