Hi, guys. I suggest mark as deprecated the IgniteMXBean#active(boolean) method. The Ignite#active(boolean), IgniteMXBean#active(), IgniteCluster#active(boolean) methods already deprecated and told to use the #state(ClusterState)} instead.
Should the old IgniteMXBean#state(ClusterState) method throw a not-safe deactivation exception? Or it should just be marked as deprecated? пт, 14 февр. 2020 г. в 12:18, Nikolay Izhikov <nizhi...@apache.org>: > > Hello, Vladimir. > > I think we should do the following: > > * Update Ignite documentation and write down the fact that in-memory cache > cleared on deactivation. > * Disallow, by default, deactivation of the cluster that has in-memory cache > with proper error message > «Your cluster has in-memory cache configured. During deactivation all > data from these caches will be cleared!» > * Add «—force» flag to deactivate command so administrator can force > deactivation for cluster that has both - persistent and in-memory caches > configured. > > Changes in the source code should include: > > 1. JMX beans - IgniteMXBean. > 2. Java API - Ignite#active and Ignite#cluster#state - because active method > have the same implementation as `IgniteMBBean#active` > 3. CLI utility - control.sh > > Igniters, what do you think? > > > 13 февр. 2020 г., в 14:19, Vladimir Steshin <vlads...@gmail.com> написал(а): > > > > Hello, everyone. > > > > > > > > I’d like to propose to make behavior of cluster deactivation the same > > independently on usage type: in code or manually with control.sh or JMX. > > Let’s put it in one place like IgniteCluster#state(ClusterState newState, > > boolean force) and require forced call for in-memory data. > > > > While I was doing the ticket I realized that the suggested previously > > solution cannot be complete. To prevent data loss via JMX I would need to > > stop executing IgniteMXBean#active(false). But this causes stopping of > > Ignite#active(false) too. The problem relies in single implementation for > > both interfaces in IgniteKernal#active(boolean). It has to act differently > > depending on where it is called from: JMX/CLI or code. > > > > > > > > Any thoughts? > > > > чт, 30 янв. 2020 г. в 13:08, Alexey Goncharuk <alexey.goncha...@gmail.com>: > > > >> I agree on CLI and JMX because those interfaces can be used by a system > >> administrator and can be invoked by mistake. > >> > >> As for the Java API, personally, I find it strange to add 'force' or > >> 'confirm' flags to it because it is very unlikely that such an invocation > >> is done by mistake. Such mistakes are caught during the testing phase and > >> developers will end up hard-coding 'true' as a flag anyways. > >> > -- Best wishes, Amelchev Nikita
