Hi folks. I created a ticket for this (IGNITE-12614):
---- Currently, anyone is able to silently deactivate cluster with command line utility (control.sh). Probably with JMX too. Same for the API: Java API – Ignite.cluster.state(). That would lead to data loss when the persistence is off. In-memory data is erased during deactivation. Such behavior can be considered as unexpected to user. Suggestions for the CLI/JMX: 1) disallow silent deactivation of cluster keeping caches. Show a warning like “Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!” 2) Add param ‘--force’ which skips the warning message. ----- Going to fix the problem if there are no disagreement <https://www.linguee.com/english-russian/translation/disagreement.html>s пт, 31 янв. 2020 г. в 13:17, Ivan Pavlukhin <vololo...@gmail.com>: > For me it looks like some coincidence effect. I understand that we get > such behavior because deactivation works the same way as for > persistent caches. Was cluster activation/deactivation designed and > described for in-memory caches? Current behavior sounds for me a as > big risk. I expect a lot of upset users unexpectedly purged all their > data. > > пт, 31 янв. 2020 г. в 00:00, Alexey Goncharuk <alexey.goncha...@gmail.com > >: > > > > Because originally the sole purpose of deactivation was resource > > deallocation. > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <dma...@apache.org>: > > > > > Such a revelation for me that data is purged from RAM if someone > > > deactivates the cluster. Alex, do you remember why we decided to > implement > > > it this way initially? > > > > > > - > > > Denis > > > > > > > > > On Thu, Jan 30, 2020 at 2:09 AM Alexey Goncharuk < > > > alexey.goncha...@gmail.com> > > > wrote: > > > > > > > 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 regards, > Ivan Pavlukhin >
