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 <alexey.scherbak...@gmail.com >: > 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 <vololo...@gmail.com>: > >> 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 <alexey.goncha...@gmail.com >> >: >> > 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 <vololo...@gmail.com> >> >> 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 <ptupit...@apache.org>: >> >> > > +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 >> >> > > <alexey.goncha...@gmail.com> >> >> > > 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
