Hello, Igniters.
I found really confusing results of the simple test. Data from the in-memory cache are vanished after change cluster state to INACTIVE/ACTIVE. Is this a bug or expected behavior? ``` public class ClusterDeactivateTest extends GridCommonAbstractTest { String name = "my-cache"; /** */ @Test public void testDataPresent() throws Exception { IgniteEx i = startGrid(0); i.createCache(name).put(1L, 1L); assertEquals(1L, i.cache(name).get(1L)); i.cluster().state(ClusterState.INACTIVE); i.cluster().state(ClusterState.ACTIVE); assertEquals(1L, i.cache(name).get(1L)); //Assertion error here! } } ``` |
Nikolay,
Inactive state deallocates all possible resources by design, including the data regions. If data region is not backed by a persistent storage, the data is lost, this is an expected behavior. ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov <[hidden email]>: > Hello, Igniters. > > I found really confusing results of the simple test. > Data from the in-memory cache are vanished after change cluster state to > INACTIVE/ACTIVE. > > Is this a bug or expected behavior? > > > ``` > public class ClusterDeactivateTest extends GridCommonAbstractTest { > String name = "my-cache"; > > /** */ > @Test > public void testDataPresent() throws Exception { > IgniteEx i = startGrid(0); > > i.createCache(name).put(1L, 1L); > > assertEquals(1L, i.cache(name).get(1L)); > > i.cluster().state(ClusterState.INACTIVE); > i.cluster().state(ClusterState.ACTIVE); > > assertEquals(1L, i.cache(name).get(1L)); //Assertion error here! > } > } > ``` |
Hello, Alexey.
Thanks for the feedback. It seems for me as a very unexpected behavior from the users point of view. I propose to 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. What do you think? > 30 янв. 2020 г., в 12:32, Alexey Goncharuk <[hidden email]> написал(а): > > Nikolay, > > Inactive state deallocates all possible resources by design, including the > data regions. If data region is not backed by a persistent storage, the > data is lost, this is an expected behavior. > > ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov <[hidden email]>: > >> Hello, Igniters. >> >> I found really confusing results of the simple test. >> Data from the in-memory cache are vanished after change cluster state to >> INACTIVE/ACTIVE. >> >> Is this a bug or expected behavior? >> >> >> ``` >> public class ClusterDeactivateTest extends GridCommonAbstractTest { >> String name = "my-cache"; >> >> /** */ >> @Test >> public void testDataPresent() throws Exception { >> IgniteEx i = startGrid(0); >> >> i.createCache(name).put(1L, 1L); >> >> assertEquals(1L, i.cache(name).get(1L)); >> >> i.cluster().state(ClusterState.INACTIVE); >> i.cluster().state(ClusterState.ACTIVE); >> >> assertEquals(1L, i.cache(name).get(1L)); //Assertion error here! >> } >> } >> ``` |
Nikolay,
This change will affect only the command-line utility, correct? No changes for the public API are planned? чт, 30 янв. 2020 г. в 12:46, Nikolay Izhikov <[hidden email]>: > Hello, Alexey. > > Thanks for the feedback. > It seems for me as a very unexpected behavior from the users point of view. > > I propose to 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. > > What do you think? > > > > 30 янв. 2020 г., в 12:32, Alexey Goncharuk <[hidden email]> > написал(а): > > > > Nikolay, > > > > Inactive state deallocates all possible resources by design, including > the > > data regions. If data region is not backed by a persistent storage, the > > data is lost, this is an expected behavior. > > > > ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov <[hidden email]>: > > > >> Hello, Igniters. > >> > >> I found really confusing results of the simple test. > >> Data from the in-memory cache are vanished after change cluster state to > >> INACTIVE/ACTIVE. > >> > >> Is this a bug or expected behavior? > >> > >> > >> ``` > >> public class ClusterDeactivateTest extends GridCommonAbstractTest { > >> String name = "my-cache"; > >> > >> /** */ > >> @Test > >> public void testDataPresent() throws Exception { > >> IgniteEx i = startGrid(0); > >> > >> i.createCache(name).put(1L, 1L); > >> > >> assertEquals(1L, i.cache(name).get(1L)); > >> > >> i.cluster().state(ClusterState.INACTIVE); > >> i.cluster().state(ClusterState.ACTIVE); > >> > >> assertEquals(1L, i.cache(name).get(1L)); //Assertion error here! > >> } > >> } > >> ``` > > |
As far as I know we have several places to manage cluster state:
1. Java API - Ignite#cluster#state 2. CLI utility - control.sh 3. JMX beans(can we manage cluster state from JMX?) I think we should add new parameter to the all management APIs. What do you think? > 30 янв. 2020 г., в 12:51, Alexey Goncharuk <[hidden email]> написал(а): > > Nikolay, > > This change will affect only the command-line utility, correct? No changes > for the public API are planned? > > чт, 30 янв. 2020 г. в 12:46, Nikolay Izhikov <[hidden email]>: > >> Hello, Alexey. >> >> Thanks for the feedback. >> It seems for me as a very unexpected behavior from the users point of view. >> >> I propose to 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. >> >> What do you think? >> >> >>> 30 янв. 2020 г., в 12:32, Alexey Goncharuk <[hidden email]> >> написал(а): >>> >>> Nikolay, >>> >>> Inactive state deallocates all possible resources by design, including >> the >>> data regions. If data region is not backed by a persistent storage, the >>> data is lost, this is an expected behavior. >>> >>> ср, 29 янв. 2020 г. в 19:18, Nikolay Izhikov <[hidden email]>: >>> >>>> Hello, Igniters. >>>> >>>> I found really confusing results of the simple test. >>>> Data from the in-memory cache are vanished after change cluster state to >>>> INACTIVE/ACTIVE. >>>> >>>> Is this a bug or expected behavior? >>>> >>>> >>>> ``` >>>> public class ClusterDeactivateTest extends GridCommonAbstractTest { >>>> String name = "my-cache"; >>>> >>>> /** */ >>>> @Test >>>> public void testDataPresent() throws Exception { >>>> IgniteEx i = startGrid(0); >>>> >>>> i.createCache(name).put(1L, 1L); >>>> >>>> assertEquals(1L, i.cache(name).get(1L)); >>>> >>>> i.cluster().state(ClusterState.INACTIVE); >>>> i.cluster().state(ClusterState.ACTIVE); >>>> >>>> assertEquals(1L, i.cache(name).get(1L)); //Assertion error here! >>>> } >>>> } >>>> ``` >> >> |
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. |
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 <[hidden email]> 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. > |
Because originally the sole purpose of deactivation was resource
deallocation. чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > 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 < > [hidden email]> > 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. > > > |
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 <[hidden email]>: > > Because originally the sole purpose of deactivation was resource > deallocation. > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > > > 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 < > > [hidden email]> > > 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 |
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 <[hidden email]>: > 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 <[hidden email] > >: > > > > Because originally the sole purpose of deactivation was resource > > deallocation. > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > > > > > 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 < > > > [hidden email]> > > > 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 > |
Go for it, Vladimir!
> 31 янв. 2020 г., в 16:15, Vladimir Steshin <[hidden email]> написал(а): > > 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 <[hidden email]>: > >> 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 <[hidden email] >>> : >>> >>> Because originally the sole purpose of deactivation was resource >>> deallocation. >>> >>> чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: >>> >>>> 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 < >>>> [hidden email]> >>>> 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 >> |
In reply to this post by Ivan Pavlukhin
Back up Ivan's opinion here. Initially, the activation/deactivation was
created for the baseline topology designed for cases with native persistence. My thinking was that the mechanism itended to prevent data inconsistencies while nodes with data on the disk will be in the process of joining the cluster. Artem, could you please update the docs bringing this to the attention of the user community? https://issues.apache.org/jira/browse/IGNITE-12615 AG, what if we don't purge data from memory at least for the caches not backed by the native persistence? Is this a big deal? We can certainly put this off by my guts feel we'll return to this question sooner or later. - Denis On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin <[hidden email]> wrote: > 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 <[hidden email] > >: > > > > Because originally the sole purpose of deactivation was resource > > deallocation. > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > > > > > 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 < > > > [hidden email]> > > > 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 > |
I do not mind making this change if we explicitly and clearly define what
'new inactive state' means. What should happen if a partition is lost in inactive state? What if such node joins back the cluster after? Etc. пт, 31 янв. 2020 г. в 20:57, Denis Magda <[hidden email]>: > Back up Ivan's opinion here. Initially, the activation/deactivation was > created for the baseline topology designed for cases with native > persistence. My thinking was that the mechanism itended to prevent data > inconsistencies while nodes with data on the disk will be in the process of > joining the cluster. > > Artem, could you please update the docs bringing this to the attention of > the user community? > https://issues.apache.org/jira/browse/IGNITE-12615 > > AG, what if we don't purge data from memory at least for the caches not > backed by the native persistence? Is this a big deal? We can certainly put > this off by my guts feel we'll return to this question sooner or later. > > - > Denis > > > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin <[hidden email]> > wrote: > > > 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 < > [hidden email] > > >: > > > > > > Because originally the sole purpose of deactivation was resource > > > deallocation. > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > > > > > > > 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 < > > > > [hidden email]> > > > > 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 > > > |
Folks,
For a long time we have a flag [1] It does almost what we want here. I suggest to make this behavior default and rework it to keep data in memory as well (we already have special "recovery" mode for caches). [1] org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk <[hidden email]>: > I do not mind making this change if we explicitly and clearly define what > 'new inactive state' means. What should happen if a partition is lost in > inactive state? What if such node joins back the cluster after? Etc. > > пт, 31 янв. 2020 г. в 20:57, Denis Magda <[hidden email]>: > > > Back up Ivan's opinion here. Initially, the activation/deactivation was > > created for the baseline topology designed for cases with native > > persistence. My thinking was that the mechanism itended to prevent data > > inconsistencies while nodes with data on the disk will be in the process > of > > joining the cluster. > > > > Artem, could you please update the docs bringing this to the attention of > > the user community? > > https://issues.apache.org/jira/browse/IGNITE-12615 > > > > AG, what if we don't purge data from memory at least for the caches not > > backed by the native persistence? Is this a big deal? We can certainly > put > > this off by my guts feel we'll return to this question sooner or later. > > > > - > > Denis > > > > > > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin <[hidden email]> > > wrote: > > > > > 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 < > > [hidden email] > > > >: > > > > > > > > Because originally the sole purpose of deactivation was resource > > > > deallocation. > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > > > > > > > > > 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 < > > > > > [hidden email]> > > > > > 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 > > > > > > -- Best regards, Alexei Scherbakov |
Alexey Goncharuk,
I see no issues with "lost" partitions. The same is possible right now in persistence mode. Node can be killed and data erased while grid is deactivated. After re-join it should rebalance itself from existing owners (if any exists). вт, 4 февр. 2020 г. в 10:54, Alexei Scherbakov <[hidden email] >: > Folks, > > For a long time we have a flag [1] > > It does almost what we want here. > > I suggest to make this behavior default and rework it to keep data in > memory as well (we already have special "recovery" mode for caches). > > > [1] org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk <[hidden email] > >: > >> I do not mind making this change if we explicitly and clearly define what >> 'new inactive state' means. What should happen if a partition is lost in >> inactive state? What if such node joins back the cluster after? Etc. >> >> пт, 31 янв. 2020 г. в 20:57, Denis Magda <[hidden email]>: >> >> > Back up Ivan's opinion here. Initially, the activation/deactivation was >> > created for the baseline topology designed for cases with native >> > persistence. My thinking was that the mechanism itended to prevent data >> > inconsistencies while nodes with data on the disk will be in the >> process of >> > joining the cluster. >> > >> > Artem, could you please update the docs bringing this to the attention >> of >> > the user community? >> > https://issues.apache.org/jira/browse/IGNITE-12615 >> > >> > AG, what if we don't purge data from memory at least for the caches not >> > backed by the native persistence? Is this a big deal? We can certainly >> put >> > this off by my guts feel we'll return to this question sooner or later. >> > >> > - >> > Denis >> > >> > >> > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin <[hidden email]> >> > wrote: >> > >> > > 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 < >> > [hidden email] >> > > >: >> > > > >> > > > Because originally the sole purpose of deactivation was resource >> > > > deallocation. >> > > > >> > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: >> > > > >> > > > > 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 < >> > > > > [hidden email]> >> > > > > 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 >> > > >> > >> > > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Alexei Scherbakov |
In reply to this post by Alexei Scherbakov
That's the best solution for this scenario. Should we readjust the already
created ticket [1] suggesting to implement the changes of Alex Scherbakov instead? [1] https://issues.apache.org/jira/browse/IGNITE-12614 - Denis On Mon, Feb 3, 2020 at 11:54 PM Alexei Scherbakov < [hidden email]> wrote: > Folks, > > For a long time we have a flag [1] > > It does almost what we want here. > > I suggest to make this behavior default and rework it to keep data in > memory as well (we already have special "recovery" mode for caches). > > [1] > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk <[hidden email] > >: > > > I do not mind making this change if we explicitly and clearly define what > > 'new inactive state' means. What should happen if a partition is lost in > > inactive state? What if such node joins back the cluster after? Etc. > > > > пт, 31 янв. 2020 г. в 20:57, Denis Magda <[hidden email]>: > > > > > Back up Ivan's opinion here. Initially, the activation/deactivation was > > > created for the baseline topology designed for cases with native > > > persistence. My thinking was that the mechanism itended to prevent data > > > inconsistencies while nodes with data on the disk will be in the > process > > of > > > joining the cluster. > > > > > > Artem, could you please update the docs bringing this to the attention > of > > > the user community? > > > https://issues.apache.org/jira/browse/IGNITE-12615 > > > > > > AG, what if we don't purge data from memory at least for the caches not > > > backed by the native persistence? Is this a big deal? We can certainly > > put > > > this off by my guts feel we'll return to this question sooner or later. > > > > > > - > > > Denis > > > > > > > > > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin <[hidden email]> > > > wrote: > > > > > > > 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 < > > > [hidden email] > > > > >: > > > > > > > > > > Because originally the sole purpose of deactivation was resource > > > > > deallocation. > > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > > > > > > > > > > > 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 < > > > > > > [hidden email]> > > > > > > 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 > > > > > > > > > > > > -- > > Best regards, > Alexei Scherbakov > |
Hello all.
Denis, which changes exactly? In current implementation of ticket [2] flag [1] is checked before requiring --force flag and showing any warnings. Do we need to set reuse-memory-on-deactivate to true by default? [1] org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE [2] https://issues.apache.org/jira/browse/IGNITE-12614 вт, 4 февр. 2020 г. в 22:45, Denis Magda <[hidden email]>: > That's the best solution for this scenario. Should we readjust the already > created ticket [1] suggesting to implement the changes of Alex Scherbakov > instead? > > [1] https://issues.apache.org/jira/browse/IGNITE-12614 > > - > Denis > > > On Mon, Feb 3, 2020 at 11:54 PM Alexei Scherbakov < > [hidden email]> wrote: > > > Folks, > > > > For a long time we have a flag [1] > > > > It does almost what we want here. > > > > I suggest to make this behavior default and rework it to keep data in > > memory as well (we already have special "recovery" mode for caches). > > > > [1] > > > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > > > > > пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk < > [hidden email] > > >: > > > > > I do not mind making this change if we explicitly and clearly define > what > > > 'new inactive state' means. What should happen if a partition is lost > in > > > inactive state? What if such node joins back the cluster after? Etc. > > > > > > пт, 31 янв. 2020 г. в 20:57, Denis Magda <[hidden email]>: > > > > > > > Back up Ivan's opinion here. Initially, the activation/deactivation > was > > > > created for the baseline topology designed for cases with native > > > > persistence. My thinking was that the mechanism itended to prevent > data > > > > inconsistencies while nodes with data on the disk will be in the > > process > > > of > > > > joining the cluster. > > > > > > > > Artem, could you please update the docs bringing this to the > attention > > of > > > > the user community? > > > > https://issues.apache.org/jira/browse/IGNITE-12615 > > > > > > > > AG, what if we don't purge data from memory at least for the caches > not > > > > backed by the native persistence? Is this a big deal? We can > certainly > > > put > > > > this off by my guts feel we'll return to this question sooner or > later. > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin <[hidden email]> > > > > wrote: > > > > > > > > > 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 < > > > > [hidden email] > > > > > >: > > > > > > > > > > > > Because originally the sole purpose of deactivation was resource > > > > > > deallocation. > > > > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > > > > > > > > > > > > > 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 < > > > > > > > [hidden email]> > > > > > > > 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 > > > > > > > > > > > > > > > > > > -- > > > > Best regards, > > Alexei Scherbakov > > > |
Hi Vladimir,
Yes, I'm suggesting us to enable this flag by org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE default instead of introducing --force flag and showing any warnings. - Denis On Wed, Feb 5, 2020 at 2:33 AM Vladimir Steshin <[hidden email]> wrote: > Hello all. > > Denis, which changes exactly? In current implementation of ticket [2] flag > [1] is checked before requiring --force flag and showing any warnings. Do > we need to set reuse-memory-on-deactivate to true by default? > > [1] > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > [2] https://issues.apache.org/jira/browse/IGNITE-12614 > > > вт, 4 февр. 2020 г. в 22:45, Denis Magda <[hidden email]>: > > > That's the best solution for this scenario. Should we readjust the > already > > created ticket [1] suggesting to implement the changes of Alex Scherbakov > > instead? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12614 > > > > - > > Denis > > > > > > On Mon, Feb 3, 2020 at 11:54 PM Alexei Scherbakov < > > [hidden email]> wrote: > > > > > Folks, > > > > > > For a long time we have a flag [1] > > > > > > It does almost what we want here. > > > > > > I suggest to make this behavior default and rework it to keep data in > > > memory as well (we already have special "recovery" mode for caches). > > > > > > [1] > > > > > > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > > > > > > > > > пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk < > > [hidden email] > > > >: > > > > > > > I do not mind making this change if we explicitly and clearly define > > what > > > > 'new inactive state' means. What should happen if a partition is lost > > in > > > > inactive state? What if such node joins back the cluster after? Etc. > > > > > > > > пт, 31 янв. 2020 г. в 20:57, Denis Magda <[hidden email]>: > > > > > > > > > Back up Ivan's opinion here. Initially, the activation/deactivation > > was > > > > > created for the baseline topology designed for cases with native > > > > > persistence. My thinking was that the mechanism itended to prevent > > data > > > > > inconsistencies while nodes with data on the disk will be in the > > > process > > > > of > > > > > joining the cluster. > > > > > > > > > > Artem, could you please update the docs bringing this to the > > attention > > > of > > > > > the user community? > > > > > https://issues.apache.org/jira/browse/IGNITE-12615 > > > > > > > > > > AG, what if we don't purge data from memory at least for the caches > > not > > > > > backed by the native persistence? Is this a big deal? We can > > certainly > > > > put > > > > > this off by my guts feel we'll return to this question sooner or > > later. > > > > > > > > > > - > > > > > Denis > > > > > > > > > > > > > > > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin < > [hidden email]> > > > > > wrote: > > > > > > > > > > > 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 < > > > > > [hidden email] > > > > > > >: > > > > > > > > > > > > > > Because originally the sole purpose of deactivation was > resource > > > > > > > deallocation. > > > > > > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email]>: > > > > > > > > > > > > > > > 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 < > > > > > > > > [hidden email]> > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > Alexei Scherbakov > > > > > > |
Denis, but why reuse-data-on-deactivate was disabled by default? There
should be a reason for that. Any data consistency issues when node gets activated anew? We may use both solutions because the flag can be switched off again. ср, 5 февр. 2020 г. в 20:47, Denis Magda <[hidden email]>: > Hi Vladimir, > > Yes, I'm suggesting us to enable this flag by > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > default instead of introducing --force flag and showing any warnings. > > - > Denis > > > On Wed, Feb 5, 2020 at 2:33 AM Vladimir Steshin <[hidden email]> > wrote: > > > Hello all. > > > > Denis, which changes exactly? In current implementation of ticket [2] > flag > > [1] is checked before requiring --force flag and showing any warnings. Do > > we need to set reuse-memory-on-deactivate to true by default? > > > > [1] > > > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > [2] https://issues.apache.org/jira/browse/IGNITE-12614 > > > > > > вт, 4 февр. 2020 г. в 22:45, Denis Magda <[hidden email]>: > > > > > That's the best solution for this scenario. Should we readjust the > > already > > > created ticket [1] suggesting to implement the changes of Alex > Scherbakov > > > instead? > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12614 > > > > > > - > > > Denis > > > > > > > > > On Mon, Feb 3, 2020 at 11:54 PM Alexei Scherbakov < > > > [hidden email]> wrote: > > > > > > > Folks, > > > > > > > > For a long time we have a flag [1] > > > > > > > > It does almost what we want here. > > > > > > > > I suggest to make this behavior default and rework it to keep data in > > > > memory as well (we already have special "recovery" mode for caches). > > > > > > > > [1] > > > > > > > > > > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > > > > > > > > > > > > > пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk < > > > [hidden email] > > > > >: > > > > > > > > > I do not mind making this change if we explicitly and clearly > define > > > what > > > > > 'new inactive state' means. What should happen if a partition is > lost > > > in > > > > > inactive state? What if such node joins back the cluster after? > Etc. > > > > > > > > > > пт, 31 янв. 2020 г. в 20:57, Denis Magda <[hidden email]>: > > > > > > > > > > > Back up Ivan's opinion here. Initially, the > activation/deactivation > > > was > > > > > > created for the baseline topology designed for cases with native > > > > > > persistence. My thinking was that the mechanism itended to > prevent > > > data > > > > > > inconsistencies while nodes with data on the disk will be in the > > > > process > > > > > of > > > > > > joining the cluster. > > > > > > > > > > > > Artem, could you please update the docs bringing this to the > > > attention > > > > of > > > > > > the user community? > > > > > > https://issues.apache.org/jira/browse/IGNITE-12615 > > > > > > > > > > > > AG, what if we don't purge data from memory at least for the > caches > > > not > > > > > > backed by the native persistence? Is this a big deal? We can > > > certainly > > > > > put > > > > > > this off by my guts feel we'll return to this question sooner or > > > later. > > > > > > > > > > > > - > > > > > > Denis > > > > > > > > > > > > > > > > > > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin < > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > 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 < > > > > > > [hidden email] > > > > > > > >: > > > > > > > > > > > > > > > > Because originally the sole purpose of deactivation was > > resource > > > > > > > > deallocation. > > > > > > > > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <[hidden email] > >: > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > [hidden email]> > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > Alexei Scherbakov > > > > > > > > > > |
I believe there might be a consistency-related reason why this flag was
disabled by default for caches that store data in Ignite native persistence. I hope, Alex Goncharuk or Scherbakov can shed some light on this. As for the memory-only caches or caches backed up by a CacheStore such as an RDBMS, enabling of the flag should be harmless. Once we do this, we'll eliminate the need to load the data back into the cluster which can be a time-consuming operation depending on the data volume. - Denis On Wed, Feb 5, 2020 at 11:58 AM Vladimir Steshin <[hidden email]> wrote: > Denis, but why reuse-data-on-deactivate was disabled by default? There > should be a reason for that. Any data consistency issues when node gets > activated anew? We may use both solutions because the flag can be switched > off again. > > ср, 5 февр. 2020 г. в 20:47, Denis Magda <[hidden email]>: > > > Hi Vladimir, > > > > Yes, I'm suggesting us to enable this flag by > > > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > default instead of introducing --force flag and showing any warnings. > > > > - > > Denis > > > > > > On Wed, Feb 5, 2020 at 2:33 AM Vladimir Steshin <[hidden email]> > > wrote: > > > > > Hello all. > > > > > > Denis, which changes exactly? In current implementation of ticket [2] > > flag > > > [1] is checked before requiring --force flag and showing any warnings. > Do > > > we need to set reuse-memory-on-deactivate to true by default? > > > > > > [1] > > > > > > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-12614 > > > > > > > > > вт, 4 февр. 2020 г. в 22:45, Denis Magda <[hidden email]>: > > > > > > > That's the best solution for this scenario. Should we readjust the > > > already > > > > created ticket [1] suggesting to implement the changes of Alex > > Scherbakov > > > > instead? > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12614 > > > > > > > > - > > > > Denis > > > > > > > > > > > > On Mon, Feb 3, 2020 at 11:54 PM Alexei Scherbakov < > > > > [hidden email]> wrote: > > > > > > > > > Folks, > > > > > > > > > > For a long time we have a flag [1] > > > > > > > > > > It does almost what we want here. > > > > > > > > > > I suggest to make this behavior default and rework it to keep data > in > > > > > memory as well (we already have special "recovery" mode for > caches). > > > > > > > > > > [1] > > > > > > > > > > > > > > > org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > > > > > > > > > > > > > > > > > пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk < > > > > [hidden email] > > > > > >: > > > > > > > > > > > I do not mind making this change if we explicitly and clearly > > define > > > > what > > > > > > 'new inactive state' means. What should happen if a partition is > > lost > > > > in > > > > > > inactive state? What if such node joins back the cluster after? > > Etc. > > > > > > > > > > > > пт, 31 янв. 2020 г. в 20:57, Denis Magda <[hidden email]>: > > > > > > > > > > > > > Back up Ivan's opinion here. Initially, the > > activation/deactivation > > > > was > > > > > > > created for the baseline topology designed for cases with > native > > > > > > > persistence. My thinking was that the mechanism itended to > > prevent > > > > data > > > > > > > inconsistencies while nodes with data on the disk will be in > the > > > > > process > > > > > > of > > > > > > > joining the cluster. > > > > > > > > > > > > > > Artem, could you please update the docs bringing this to the > > > > attention > > > > > of > > > > > > > the user community? > > > > > > > https://issues.apache.org/jira/browse/IGNITE-12615 > > > > > > > > > > > > > > AG, what if we don't purge data from memory at least for the > > caches > > > > not > > > > > > > backed by the native persistence? Is this a big deal? We can > > > > certainly > > > > > > put > > > > > > > this off by my guts feel we'll return to this question sooner > or > > > > later. > > > > > > > > > > > > > > - > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin < > > > [hidden email]> > > > > > > > wrote: > > > > > > > > > > > > > > > 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 < > > > > > > > [hidden email] > > > > > > > > >: > > > > > > > > > > > > > > > > > > Because originally the sole purpose of deactivation was > > > resource > > > > > > > > > deallocation. > > > > > > > > > > > > > > > > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda < > [hidden email] > > >: > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > [hidden email]> > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Best regards, > > > > > Alexei Scherbakov > > > > > > > > > > > > > > > |
Free forum by Nabble | Edit this page |