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