> +1 to deprecate rebalanceOrder and remove related functionality, Meant to "rework related functionality" not "remove".
чт, 13 февр. 2020 г. в 12:47, Pavel Pereslegin <xxt...@gmail.com>: > > Hello, > > +1 to deprecate rebalanceOrder and remove related functionality, > should we create a separate ticket for this? > > Btw, as I understand, SYNC mode is only useful for in-memory caches, > because when persistence is enabled (and WAL is disabled during > rebalancing), even "ignite-sys-cache" owns partitions only after all > cache groups are rebalanced. Thus, even utility cache is still > inoperable after node startup when persistence is enabled. Do we > really need to wait for SYNC caches when a node starts with enabled > persistence or should we enabled WAL for SYNC-caches? > > чт, 13 февр. 2020 г. в 11:13, Ivan Rakov <ivan.glu...@gmail.com>: > > > > Hello, > > > > +1 from me for rebalance delay deprecation. > > I can imagine only one actual case for this option: prevent excessive load > > on the cluster in case of temporary short-term topology changes (e.g. node > > is stopped for a while and then returned back). > > Now it's handled by baseline auto adjustment in a much more correct way: > > partitions are not reassigned within a maintenance interval (unlike with > > the rebalance delay). > > I also don't think that ability to configure rebalance delay per cache is > > crucial. > > > > > rebalanceOrder is also useless, agreed. > > +1 > > Except for one case: we may want to rebalance caches with > > CacheRebalanceMode.SYNC first. But anyway, this behavior doesn't require a > > separate property to be enabled. > > > > On Wed, Feb 12, 2020 at 4:54 PM Alexei Scherbakov < > > alexey.scherbak...@gmail.com> wrote: > > > > > Maxim, > > > > > > rebalanceDelay was introduced before the BLT appear in the product to > > > solve > > > scenarios which are now solved by BLT. > > > > > > It's pointless for me having it in the product since BLT was introduced. > > > > > > I do not think delaying rebalancing per cache group has any meaning. I > > > cannot image any reason for it. > > > > > > rebalanceOrder is also useless, agreed. > > > > > > > > > > > > > > > ср, 12 февр. 2020 г. в 16:19, Maxim Muzafarov <mmu...@apache.org>: > > > > > > > Alexey, > > > > > > > > Why do you think delaying of historical rebalance (on BLT node join) > > > > for particular cache groups is not the real world use case? Probably > > > > the same topic may be started on user-list to collect more use cases > > > > from real users. > > > > > > > > In general, I support reducing the number of available rebalance > > > > configuration parameters, but we should do it really carefully. > > > > I can also propose - rebalanceOrder param for removing. > > > > > > > > On Wed, 12 Feb 2020 at 15:50, Alexei Scherbakov > > > > <alexey.scherbak...@gmail.com> wrote: > > > > > > > > > > Maxim, > > > > > > > > > > In general rebalanceDelay is used to delay/disable rebalance then > > > > topology > > > > > is changed. > > > > > Right now we have BLT to avoid unnecesary rebalancing when topology is > > > > > changed. > > > > > If a node left from cluster topology no rebalancing happens until the > > > > node > > > > > explicitly removed from baseline topology. > > > > > > > > > > I would like to know real world scenarios which can not be covered by > > > BLT > > > > > configuration. > > > > > > > > > > > > > > > > > > > > ср, 12 февр. 2020 г. в 15:16, Maxim Muzafarov <mmu...@apache.org>: > > > > > > > > > > > Alexey, > > > > > > > > > > > > > All scenarios where rebalanceDelay has meaning are handled by > > > > baseline > > > > > > topology now. > > > > > > > > > > > > Can you, please, provide more details here e.g. the whole list of > > > > > > scenarios where rebalanceDelay is used and how these handled by > > > > > > baseline topology? > > > > > > > > > > > > Actually, I doubt that it covers exactly all the cases due to > > > > > > rebalanceDelay is a "per cache group property" rather than > > > > > > "baseline" > > > > > > is meaningful for the whole topology. > > > > > > > > > > > > On Wed, 12 Feb 2020 at 12:58, Alexei Scherbakov > > > > > > <alexey.scherbak...@gmail.com> wrote: > > > > > > > > > > > > > > I've meant baseline topology. > > > > > > > > > > > > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov < > > > > > > > alexey.scherbak...@gmail.com>: > > > > > > > > > > > > > > > > > > > > > > > V.Pyatkov > > > > > > > > > > > > > > > > Doesn't rebalance topology solves it ? > > > > > > > > > > > > > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <vldpyat...@gmail.com>: > > > > > > > > > > > > > > > >> Hi, > > > > > > > >> > > > > > > > >> I am sure we can to reduce this ability, but do not completely. > > > > > > > >> We can use rebalance delay for disable it until manually > > > > triggered. > > > > > > > >> > > > > > > > >> CacheConfiguration#setRebalanceDelay(-1) > > > > > > > >> > > > > > > > >> It may helpful for cluster where can not allow performance drop > > > > from > > > > > > > >> rebalance at any time. > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> -- > > > > > > > >> Sent from: > > > http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Alexei Scherbakov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Best regards, > > > > > > > Alexei Scherbakov > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Best regards, > > > > > Alexei Scherbakov > > > > > > > > > > > > > -- > > > > > > Best regards, > > > Alexei Scherbakov > > >
