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