Вячеслав, Hi. Even if previous behavior is controversial? It allows to erase data suddenly. I would suggest to slightly change API of IgniteMXBean. It would solve the problem of single implementation IgniteKernal#active(boolean). But changing of API is prohibited. Another solution is to extract implementation of IgniteMXBean from IgniteKernal. I believe this approach is too bulky. How often Ignite#active(false) is used outside the tests? What is so wrong to use new IgniteCluster(INACTIVE, force:true)?
To the point, the PR is here: пт, 14 февр. 2020 г. в 15:57, Вячеслав Коптилин <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. > > > > > >
