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