Re: Getting rid of NONE cache rebalance mode
Alexey, Thank you for the response. > I am not sure how expiration relates to the partition ownership - once a > partition moves to a renting state, all entries are eagerly cleaned from the > memory, so there is no need for expiration. It is even better, there is nothing to do with expiration. Due to unknown reason I thought about systems not sharing actual partition distribution between nodes. 2020-07-28 18:19 GMT+03:00, Alexey Goncharuk : > Ivan, > > Sorry for a delay in reply. Yes, I was thinking about the same use-case, > and in this particular case an unexpected load on a 3rd-party database > manifests itself. I am not sure how expiration relates to the partition > ownership - once a partition moves to a renting state, all entries are > eagerly cleaned from the memory, so there is no need for expiration. > > Can you elaborate on your idea how rebalancing relates to expiration? > > вт, 21 июл. 2020 г. в 15:59, Ivan Pavlukhin : > >> Alexey, >> >> Thank you for explanation. I feel that I miss a couple bits to >> understand the picture fully. I am thinking about a case which I tend >> to call a Memcached use-case. There is a cache over underlying storage >> with read-through and expiration and without any rebalancing at all. >> When new nodes enter they take ownership for some partitions from >> already running nodes and serve client requests. Entries for not >> owning anymore partitions expire according to configuration. >> >> Actually, I have an idea. My guess is that "rebalancing" is a smarter >> and better approach than waiting for expiration. Am I right? >> >> 2020-07-21 15:31 GMT+03:00, Alexey Goncharuk >> : >> > Ivan, >> > >> > In my understanding this mode does not work at all even in the presence >> of >> > ForceKeysRequest which is now supposed to fetch values from peers in >> > case >> > of a miss. In this mode we 1) move partitions to OWNING state >> > unconditionally, and 2) choose an arbitrary OWNING node for force keys >> > request. Therefore, after a user started two additional nodes in a >> cluster, >> > the request may be mapped to a node which does not hold any data. We >> > will >> > do a read-through in this case, but it will result in significant load >> > increase on a third-party storage right after a node started, which >> > means >> > that adding a node will increase, not decrease, the load on the >> > database >> > being cached. >> > All these issues go away when (A)SYNC mode is used. >> > >> > Val, >> > The idea makes sense to me - a user can use rebalance future to wait >> > for >> > rebalance to finish. This will simplify the configuration even further. >> > >> > пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko < >> > valentin.kuliche...@gmail.com>: >> > >> >> +1 for deprecating/removing NONE mode. >> >> >> >> Alexey, what do you think about the SYNC mode? In my experience, it >> >> does >> >> not add much value as well. I would go as far as removing the >> >> rebalancingMode parameter altogether (probably in 3.0). >> >> >> >> -Val >> >> >> >> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin >> >> wrote: >> >> >> >> > Alexey, Igniters, >> >> > >> >> > Could you please outline motivation answering following questions? >> >> > 1. Does this mode generally work correctly today? >> >> > 2. Can this mode be useful at all? >> >> > >> >> > I can imagine that it might be useful in a transparent caching use >> >> > case (if I did not misunderstand). >> >> > >> >> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn : >> >> > > +1 >> >> > > >> >> > > More evidence: >> >> > > >> >> > >> >> >> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes >> >> > > >> >> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk >> >> > > >> >> > > wrote: >> >> > > >> >> > >> Igniters, >> >> > >> >> >> > >> I would like to run the idea of deprecating and probably ignoring >> >> > >> the >> >> > >> NONE >> >> > >> rebalance mode by the community. It's in the removal list for >> Ignite >> >> 3.0 >> >> > >> [1], but it looks like it still confuses and creates issues for >> >> > >> users >> >> > >> [2]. >> >> > >> >> >> > >> What about deprecating it in one of the next releases and even >> >> ignoring >> >> > >> this constant in further releases, interpreting it as ASYNC, >> >> > >> before >> >> > >> Ignite >> >> > >> 3.0? I find it hard to believe that any Ignite user actually has >> >> > >> RebalanceMode.NONE set in their configuration due to its >> >> > >> absolutely >> >> > >> unpredictable behavior. >> >> > >> >> >> > >> Thanks for your thoughts, >> >> > >> --AG >> >> > >> >> >> > >> [1] >> >> > >> >> >> > >> >> >> > >> >> >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist >> >> > >> [2] >> >> > >> >> >> > >> >> >> > >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html >> >> > >> >> >> > > >> >> > >> >> > >> >> > -- >> >> > >> >> > Best regards, >> >> > Ivan
Re: Getting rid of NONE cache rebalance mode
Ivan, Sorry for a delay in reply. Yes, I was thinking about the same use-case, and in this particular case an unexpected load on a 3rd-party database manifests itself. I am not sure how expiration relates to the partition ownership - once a partition moves to a renting state, all entries are eagerly cleaned from the memory, so there is no need for expiration. Can you elaborate on your idea how rebalancing relates to expiration? вт, 21 июл. 2020 г. в 15:59, Ivan Pavlukhin : > Alexey, > > Thank you for explanation. I feel that I miss a couple bits to > understand the picture fully. I am thinking about a case which I tend > to call a Memcached use-case. There is a cache over underlying storage > with read-through and expiration and without any rebalancing at all. > When new nodes enter they take ownership for some partitions from > already running nodes and serve client requests. Entries for not > owning anymore partitions expire according to configuration. > > Actually, I have an idea. My guess is that "rebalancing" is a smarter > and better approach than waiting for expiration. Am I right? > > 2020-07-21 15:31 GMT+03:00, Alexey Goncharuk : > > Ivan, > > > > In my understanding this mode does not work at all even in the presence > of > > ForceKeysRequest which is now supposed to fetch values from peers in case > > of a miss. In this mode we 1) move partitions to OWNING state > > unconditionally, and 2) choose an arbitrary OWNING node for force keys > > request. Therefore, after a user started two additional nodes in a > cluster, > > the request may be mapped to a node which does not hold any data. We will > > do a read-through in this case, but it will result in significant load > > increase on a third-party storage right after a node started, which means > > that adding a node will increase, not decrease, the load on the database > > being cached. > > All these issues go away when (A)SYNC mode is used. > > > > Val, > > The idea makes sense to me - a user can use rebalance future to wait for > > rebalance to finish. This will simplify the configuration even further. > > > > пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko < > > valentin.kuliche...@gmail.com>: > > > >> +1 for deprecating/removing NONE mode. > >> > >> Alexey, what do you think about the SYNC mode? In my experience, it does > >> not add much value as well. I would go as far as removing the > >> rebalancingMode parameter altogether (probably in 3.0). > >> > >> -Val > >> > >> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin > >> wrote: > >> > >> > Alexey, Igniters, > >> > > >> > Could you please outline motivation answering following questions? > >> > 1. Does this mode generally work correctly today? > >> > 2. Can this mode be useful at all? > >> > > >> > I can imagine that it might be useful in a transparent caching use > >> > case (if I did not misunderstand). > >> > > >> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn : > >> > > +1 > >> > > > >> > > More evidence: > >> > > > >> > > >> > https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes > >> > > > >> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk > >> > > > >> > > wrote: > >> > > > >> > >> Igniters, > >> > >> > >> > >> I would like to run the idea of deprecating and probably ignoring > >> > >> the > >> > >> NONE > >> > >> rebalance mode by the community. It's in the removal list for > Ignite > >> 3.0 > >> > >> [1], but it looks like it still confuses and creates issues for > >> > >> users > >> > >> [2]. > >> > >> > >> > >> What about deprecating it in one of the next releases and even > >> ignoring > >> > >> this constant in further releases, interpreting it as ASYNC, before > >> > >> Ignite > >> > >> 3.0? I find it hard to believe that any Ignite user actually has > >> > >> RebalanceMode.NONE set in their configuration due to its absolutely > >> > >> unpredictable behavior. > >> > >> > >> > >> Thanks for your thoughts, > >> > >> --AG > >> > >> > >> > >> [1] > >> > >> > >> > >> > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > >> > >> [2] > >> > >> > >> > >> > >> > > >> > http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html > >> > >> > >> > > > >> > > >> > > >> > -- > >> > > >> > Best regards, > >> > Ivan Pavlukhin > >> > > >> > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: Getting rid of NONE cache rebalance mode
As a reminder - we already have a ticket for a deprecation of rebalanceDelay as well [1] [1] https://issues.apache.org/jira/browse/IGNITE-12662 ср, 22 июл. 2020 г. в 09:39, Alexei Scherbakov : > Ivan, > My opinion the ASYNC rebalancing is a best approach for off-loading 3-d > party store, and it provides consistency. > > +1 for deprecation of NONE in the next release - ignore NONE and use ASYNC > instead > For those who require absence of rebalancing for some reason still be > possible to use rebalanceDelay=infinity. > > +1 for removal of rebalanceMode in 3.0. > Note what we still require SYNC logic internally for system cache in some > places. > > > > вт, 21 июл. 2020 г. в 15:59, Ivan Pavlukhin : > >> Alexey, >> >> Thank you for explanation. I feel that I miss a couple bits to >> understand the picture fully. I am thinking about a case which I tend >> to call a Memcached use-case. There is a cache over underlying storage >> with read-through and expiration and without any rebalancing at all. >> When new nodes enter they take ownership for some partitions from >> already running nodes and serve client requests. Entries for not >> owning anymore partitions expire according to configuration. >> >> Actually, I have an idea. My guess is that "rebalancing" is a smarter >> and better approach than waiting for expiration. Am I right? >> >> 2020-07-21 15:31 GMT+03:00, Alexey Goncharuk > >: >> > Ivan, >> > >> > In my understanding this mode does not work at all even in the presence >> of >> > ForceKeysRequest which is now supposed to fetch values from peers in >> case >> > of a miss. In this mode we 1) move partitions to OWNING state >> > unconditionally, and 2) choose an arbitrary OWNING node for force keys >> > request. Therefore, after a user started two additional nodes in a >> cluster, >> > the request may be mapped to a node which does not hold any data. We >> will >> > do a read-through in this case, but it will result in significant load >> > increase on a third-party storage right after a node started, which >> means >> > that adding a node will increase, not decrease, the load on the database >> > being cached. >> > All these issues go away when (A)SYNC mode is used. >> > >> > Val, >> > The idea makes sense to me - a user can use rebalance future to wait for >> > rebalance to finish. This will simplify the configuration even further. >> > >> > пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko < >> > valentin.kuliche...@gmail.com>: >> > >> >> +1 for deprecating/removing NONE mode. >> >> >> >> Alexey, what do you think about the SYNC mode? In my experience, it >> does >> >> not add much value as well. I would go as far as removing the >> >> rebalancingMode parameter altogether (probably in 3.0). >> >> >> >> -Val >> >> >> >> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin >> >> wrote: >> >> >> >> > Alexey, Igniters, >> >> > >> >> > Could you please outline motivation answering following questions? >> >> > 1. Does this mode generally work correctly today? >> >> > 2. Can this mode be useful at all? >> >> > >> >> > I can imagine that it might be useful in a transparent caching use >> >> > case (if I did not misunderstand). >> >> > >> >> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn : >> >> > > +1 >> >> > > >> >> > > More evidence: >> >> > > >> >> > >> >> >> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes >> >> > > >> >> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk >> >> > > >> >> > > wrote: >> >> > > >> >> > >> Igniters, >> >> > >> >> >> > >> I would like to run the idea of deprecating and probably ignoring >> >> > >> the >> >> > >> NONE >> >> > >> rebalance mode by the community. It's in the removal list for >> Ignite >> >> 3.0 >> >> > >> [1], but it looks like it still confuses and creates issues for >> >> > >> users >> >> > >> [2]. >> >> > >> >> >> > >> What about deprecating it in one of the next releases and even >> >> ignoring >> >> > >> this constant in further releases, interpreting it as ASYNC, >> before >> >> > >> Ignite >> >> > >> 3.0? I find it hard to believe that any Ignite user actually has >> >> > >> RebalanceMode.NONE set in their configuration due to its >> absolutely >> >> > >> unpredictable behavior. >> >> > >> >> >> > >> Thanks for your thoughts, >> >> > >> --AG >> >> > >> >> >> > >> [1] >> >> > >> >> >> > >> >> >> > >> >> >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist >> >> > >> [2] >> >> > >> >> >> > >> >> >> > >> >> >> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html >> >> > >> >> >> > > >> >> > >> >> > >> >> > -- >> >> > >> >> > Best regards, >> >> > Ivan Pavlukhin >> >> > >> >> >> > >> >> >> -- >> >> Best regards, >> Ivan Pavlukhin >> > > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
Re: Getting rid of NONE cache rebalance mode
Ivan, My opinion the ASYNC rebalancing is a best approach for off-loading 3-d party store, and it provides consistency. +1 for deprecation of NONE in the next release - ignore NONE and use ASYNC instead For those who require absence of rebalancing for some reason still be possible to use rebalanceDelay=infinity. +1 for removal of rebalanceMode in 3.0. Note what we still require SYNC logic internally for system cache in some places. вт, 21 июл. 2020 г. в 15:59, Ivan Pavlukhin : > Alexey, > > Thank you for explanation. I feel that I miss a couple bits to > understand the picture fully. I am thinking about a case which I tend > to call a Memcached use-case. There is a cache over underlying storage > with read-through and expiration and without any rebalancing at all. > When new nodes enter they take ownership for some partitions from > already running nodes and serve client requests. Entries for not > owning anymore partitions expire according to configuration. > > Actually, I have an idea. My guess is that "rebalancing" is a smarter > and better approach than waiting for expiration. Am I right? > > 2020-07-21 15:31 GMT+03:00, Alexey Goncharuk : > > Ivan, > > > > In my understanding this mode does not work at all even in the presence > of > > ForceKeysRequest which is now supposed to fetch values from peers in case > > of a miss. In this mode we 1) move partitions to OWNING state > > unconditionally, and 2) choose an arbitrary OWNING node for force keys > > request. Therefore, after a user started two additional nodes in a > cluster, > > the request may be mapped to a node which does not hold any data. We will > > do a read-through in this case, but it will result in significant load > > increase on a third-party storage right after a node started, which means > > that adding a node will increase, not decrease, the load on the database > > being cached. > > All these issues go away when (A)SYNC mode is used. > > > > Val, > > The idea makes sense to me - a user can use rebalance future to wait for > > rebalance to finish. This will simplify the configuration even further. > > > > пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko < > > valentin.kuliche...@gmail.com>: > > > >> +1 for deprecating/removing NONE mode. > >> > >> Alexey, what do you think about the SYNC mode? In my experience, it does > >> not add much value as well. I would go as far as removing the > >> rebalancingMode parameter altogether (probably in 3.0). > >> > >> -Val > >> > >> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin > >> wrote: > >> > >> > Alexey, Igniters, > >> > > >> > Could you please outline motivation answering following questions? > >> > 1. Does this mode generally work correctly today? > >> > 2. Can this mode be useful at all? > >> > > >> > I can imagine that it might be useful in a transparent caching use > >> > case (if I did not misunderstand). > >> > > >> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn : > >> > > +1 > >> > > > >> > > More evidence: > >> > > > >> > > >> > https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes > >> > > > >> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk > >> > > > >> > > wrote: > >> > > > >> > >> Igniters, > >> > >> > >> > >> I would like to run the idea of deprecating and probably ignoring > >> > >> the > >> > >> NONE > >> > >> rebalance mode by the community. It's in the removal list for > Ignite > >> 3.0 > >> > >> [1], but it looks like it still confuses and creates issues for > >> > >> users > >> > >> [2]. > >> > >> > >> > >> What about deprecating it in one of the next releases and even > >> ignoring > >> > >> this constant in further releases, interpreting it as ASYNC, before > >> > >> Ignite > >> > >> 3.0? I find it hard to believe that any Ignite user actually has > >> > >> RebalanceMode.NONE set in their configuration due to its absolutely > >> > >> unpredictable behavior. > >> > >> > >> > >> Thanks for your thoughts, > >> > >> --AG > >> > >> > >> > >> [1] > >> > >> > >> > >> > >> > > >> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > >> > >> [2] > >> > >> > >> > >> > >> > > >> > http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html > >> > >> > >> > > > >> > > >> > > >> > -- > >> > > >> > Best regards, > >> > Ivan Pavlukhin > >> > > >> > > > > > -- > > Best regards, > Ivan Pavlukhin > -- Best regards, Alexei Scherbakov
Re: Getting rid of NONE cache rebalance mode
Alexey, Thank you for explanation. I feel that I miss a couple bits to understand the picture fully. I am thinking about a case which I tend to call a Memcached use-case. There is a cache over underlying storage with read-through and expiration and without any rebalancing at all. When new nodes enter they take ownership for some partitions from already running nodes and serve client requests. Entries for not owning anymore partitions expire according to configuration. Actually, I have an idea. My guess is that "rebalancing" is a smarter and better approach than waiting for expiration. Am I right? 2020-07-21 15:31 GMT+03:00, Alexey Goncharuk : > Ivan, > > In my understanding this mode does not work at all even in the presence of > ForceKeysRequest which is now supposed to fetch values from peers in case > of a miss. In this mode we 1) move partitions to OWNING state > unconditionally, and 2) choose an arbitrary OWNING node for force keys > request. Therefore, after a user started two additional nodes in a cluster, > the request may be mapped to a node which does not hold any data. We will > do a read-through in this case, but it will result in significant load > increase on a third-party storage right after a node started, which means > that adding a node will increase, not decrease, the load on the database > being cached. > All these issues go away when (A)SYNC mode is used. > > Val, > The idea makes sense to me - a user can use rebalance future to wait for > rebalance to finish. This will simplify the configuration even further. > > пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko < > valentin.kuliche...@gmail.com>: > >> +1 for deprecating/removing NONE mode. >> >> Alexey, what do you think about the SYNC mode? In my experience, it does >> not add much value as well. I would go as far as removing the >> rebalancingMode parameter altogether (probably in 3.0). >> >> -Val >> >> On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin >> wrote: >> >> > Alexey, Igniters, >> > >> > Could you please outline motivation answering following questions? >> > 1. Does this mode generally work correctly today? >> > 2. Can this mode be useful at all? >> > >> > I can imagine that it might be useful in a transparent caching use >> > case (if I did not misunderstand). >> > >> > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn : >> > > +1 >> > > >> > > More evidence: >> > > >> > >> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes >> > > >> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk >> > > >> > > wrote: >> > > >> > >> Igniters, >> > >> >> > >> I would like to run the idea of deprecating and probably ignoring >> > >> the >> > >> NONE >> > >> rebalance mode by the community. It's in the removal list for Ignite >> 3.0 >> > >> [1], but it looks like it still confuses and creates issues for >> > >> users >> > >> [2]. >> > >> >> > >> What about deprecating it in one of the next releases and even >> ignoring >> > >> this constant in further releases, interpreting it as ASYNC, before >> > >> Ignite >> > >> 3.0? I find it hard to believe that any Ignite user actually has >> > >> RebalanceMode.NONE set in their configuration due to its absolutely >> > >> unpredictable behavior. >> > >> >> > >> Thanks for your thoughts, >> > >> --AG >> > >> >> > >> [1] >> > >> >> > >> >> > >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist >> > >> [2] >> > >> >> > >> >> > >> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html >> > >> >> > > >> > >> > >> > -- >> > >> > Best regards, >> > Ivan Pavlukhin >> > >> > -- Best regards, Ivan Pavlukhin
Re: Getting rid of NONE cache rebalance mode
Ivan, In my understanding this mode does not work at all even in the presence of ForceKeysRequest which is now supposed to fetch values from peers in case of a miss. In this mode we 1) move partitions to OWNING state unconditionally, and 2) choose an arbitrary OWNING node for force keys request. Therefore, after a user started two additional nodes in a cluster, the request may be mapped to a node which does not hold any data. We will do a read-through in this case, but it will result in significant load increase on a third-party storage right after a node started, which means that adding a node will increase, not decrease, the load on the database being cached. All these issues go away when (A)SYNC mode is used. Val, The idea makes sense to me - a user can use rebalance future to wait for rebalance to finish. This will simplify the configuration even further. пн, 20 июл. 2020 г. в 21:27, Valentin Kulichenko < valentin.kuliche...@gmail.com>: > +1 for deprecating/removing NONE mode. > > Alexey, what do you think about the SYNC mode? In my experience, it does > not add much value as well. I would go as far as removing the > rebalancingMode parameter altogether (probably in 3.0). > > -Val > > On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin > wrote: > > > Alexey, Igniters, > > > > Could you please outline motivation answering following questions? > > 1. Does this mode generally work correctly today? > > 2. Can this mode be useful at all? > > > > I can imagine that it might be useful in a transparent caching use > > case (if I did not misunderstand). > > > > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn : > > > +1 > > > > > > More evidence: > > > > > > https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes > > > > > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk > > > > > > wrote: > > > > > >> Igniters, > > >> > > >> I would like to run the idea of deprecating and probably ignoring the > > >> NONE > > >> rebalance mode by the community. It's in the removal list for Ignite > 3.0 > > >> [1], but it looks like it still confuses and creates issues for users > > >> [2]. > > >> > > >> What about deprecating it in one of the next releases and even > ignoring > > >> this constant in further releases, interpreting it as ASYNC, before > > >> Ignite > > >> 3.0? I find it hard to believe that any Ignite user actually has > > >> RebalanceMode.NONE set in their configuration due to its absolutely > > >> unpredictable behavior. > > >> > > >> Thanks for your thoughts, > > >> --AG > > >> > > >> [1] > > >> > > >> > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > > >> [2] > > >> > > >> > > > http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html > > >> > > > > > > > > > -- > > > > Best regards, > > Ivan Pavlukhin > > >
Re: Getting rid of NONE cache rebalance mode
+1 for deprecating/removing NONE mode. Alexey, what do you think about the SYNC mode? In my experience, it does not add much value as well. I would go as far as removing the rebalancingMode parameter altogether (probably in 3.0). -Val On Mon, Jul 20, 2020 at 11:09 AM Ivan Pavlukhin wrote: > Alexey, Igniters, > > Could you please outline motivation answering following questions? > 1. Does this mode generally work correctly today? > 2. Can this mode be useful at all? > > I can imagine that it might be useful in a transparent caching use > case (if I did not misunderstand). > > 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn : > > +1 > > > > More evidence: > > > https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes > > > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk > > > > wrote: > > > >> Igniters, > >> > >> I would like to run the idea of deprecating and probably ignoring the > >> NONE > >> rebalance mode by the community. It's in the removal list for Ignite 3.0 > >> [1], but it looks like it still confuses and creates issues for users > >> [2]. > >> > >> What about deprecating it in one of the next releases and even ignoring > >> this constant in further releases, interpreting it as ASYNC, before > >> Ignite > >> 3.0? I find it hard to believe that any Ignite user actually has > >> RebalanceMode.NONE set in their configuration due to its absolutely > >> unpredictable behavior. > >> > >> Thanks for your thoughts, > >> --AG > >> > >> [1] > >> > >> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > >> [2] > >> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html > >> > > > > > -- > > Best regards, > Ivan Pavlukhin >
Re: Getting rid of NONE cache rebalance mode
Alexey, Igniters, Could you please outline motivation answering following questions? 1. Does this mode generally work correctly today? 2. Can this mode be useful at all? I can imagine that it might be useful in a transparent caching use case (if I did not misunderstand). 2020-07-20 20:39 GMT+03:00, Pavel Tupitsyn : > +1 > > More evidence: > https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk > > wrote: > >> Igniters, >> >> I would like to run the idea of deprecating and probably ignoring the >> NONE >> rebalance mode by the community. It's in the removal list for Ignite 3.0 >> [1], but it looks like it still confuses and creates issues for users >> [2]. >> >> What about deprecating it in one of the next releases and even ignoring >> this constant in further releases, interpreting it as ASYNC, before >> Ignite >> 3.0? I find it hard to believe that any Ignite user actually has >> RebalanceMode.NONE set in their configuration due to its absolutely >> unpredictable behavior. >> >> Thanks for your thoughts, >> --AG >> >> [1] >> >> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist >> [2] >> >> http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html >> > -- Best regards, Ivan Pavlukhin
Re: Getting rid of NONE cache rebalance mode
+1 More evidence: https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk wrote: > Igniters, > > I would like to run the idea of deprecating and probably ignoring the NONE > rebalance mode by the community. It's in the removal list for Ignite 3.0 > [1], but it looks like it still confuses and creates issues for users [2]. > > What about deprecating it in one of the next releases and even ignoring > this constant in further releases, interpreting it as ASYNC, before Ignite > 3.0? I find it hard to believe that any Ignite user actually has > RebalanceMode.NONE set in their configuration due to its absolutely > unpredictable behavior. > > Thanks for your thoughts, > --AG > > [1] > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > [2] > > http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html >
Getting rid of NONE cache rebalance mode
Igniters, I would like to run the idea of deprecating and probably ignoring the NONE rebalance mode by the community. It's in the removal list for Ignite 3.0 [1], but it looks like it still confuses and creates issues for users [2]. What about deprecating it in one of the next releases and even ignoring this constant in further releases, interpreting it as ASYNC, before Ignite 3.0? I find it hard to believe that any Ignite user actually has RebalanceMode.NONE set in their configuration due to its absolutely unpredictable behavior. Thanks for your thoughts, --AG [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist [2] http://apache-ignite-developers.2346864.n4.nabble.com/About-Rebalance-Mode-SYNC-amp-NONE-td47279.html
