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