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