[DISCUSSION] Deprecation of obsolete rebalancing functionality

[Alexei Scherbakov]

Folks,

I want to deprecate some obsolete functionality related to rebalancing.
Details in [1]

Any objections ?

[1] https://issues.apache.org/jira/browse/IGNITE-12662

--

Best regards,
Alexei Scherbakov

[Zhenya Stanilovsky]

I know guys who use this setting (may be erroneously)  = MAX_INT for real rebalance delaying (very small sla) grid without persistence. But i don`t know further algo, may be if backup nodes  become extremely small they creates the same cluster near it. Can ignite simple disable rebalance?
 

>Folks,
>
>I want to deprecate some obsolete functionality related to rebalancing.
>Details in [1]
>
>Any objections ?
>
>[1]  https://issues.apache.org/jira/browse/IGNITE-12662
>
>--
>
>Best regards,
>Alexei Scherbakov
> 

 
 
 
 

[V.Pyatkov]

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/

[Sergey-A Kosarev]

Classification: Public

Hi, Alexey.
I believe it can't be done until in-memory caches will use baseline topology [1].
In our case we are using rebalanceDelay for in-memory caches.

[1] https://issues.apache.org/jira/browse/IGNITE-8414


Kind regards,
Sergey Kosarev

-----Original Message-----
From: Zhenya Stanilovsky [mailto:[hidden email]]
Sent: 12 February 2020 11:33
To: [hidden email]
Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality



I know guys who use this setting (may be erroneously)  = MAX_INT for real rebalance delaying (very small sla) grid without persistence. But i don`t know further algo, may be if backup nodes  become extremely small they creates the same cluster near it. Can ignite simple disable rebalance?

>Folks,
>
>I want to deprecate some obsolete functionality related to rebalancing.
>Details in [1]
>
>Any objections ?
>
>[1]  https://issues.apache.org/jira/browse/IGNITE-12662
>
>--
>
>Best regards,
>Alexei Scherbakov
>

---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

[daradurvs]

Hi, Alexei!

CacheConfiguration#getRebalanceDelay was extremely useful for the
caches backed by @CacheLocalStore to prevent rebalancing during full
cluster startup/shutdown.
But @CacheLocalStore annotation is deprecated also.

I think "rebalancing delay" stuff might be useful for replicated
cached to have a gap for administrators to switch load for example.

On Wed, Feb 12, 2020 at 11:33 AM Zhenya Stanilovsky
<[hidden email]> wrote:

>
>
>
> I know guys who use this setting (may be erroneously)  = MAX_INT for real rebalance delaying (very small sla) grid without persistence. But i don`t know further algo, may be if backup nodes  become extremely small they creates the same cluster near it. Can ignite simple disable rebalance?
>
> >Folks,
> >
> >I want to deprecate some obsolete functionality related to rebalancing.
> >Details in [1]
> >
> >Any objections ?
> >
> >[1]  https://issues.apache.org/jira/browse/IGNITE-12662
> >
> >--
> >
> >Best regards,
> >Alexei Scherbakov
> >
>
>
>
>

--
Best Regards, Vyacheslav D.

[Alexei Scherbakov]

Sergey,

The ticket looks outdated.
In fact this is already implemented.

ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev <[hidden email]>:

> Classification: Public
>
> Hi, Alexey.
> I believe it can't be done until in-memory caches will use baseline
> topology [1].
> In our case we are using rebalanceDelay for in-memory caches.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8414
>
>
> Kind regards,
> Sergey Kosarev
>
> -----Original Message-----
> From: Zhenya Stanilovsky [mailto:[hidden email]]
> Sent: 12 February 2020 11:33
> To: [hidden email]
> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
>
>
>
> I know guys who use this setting (may be erroneously)  = MAX_INT for real
> rebalance delaying (very small sla) grid without persistence. But i don`t
> know further algo, may be if backup nodes  become extremely small they
> creates the same cluster near it. Can ignite simple disable rebalance?
>
> >Folks,
> >
> >I want to deprecate some obsolete functionality related to rebalancing.
> >Details in [1]
> >
> >Any objections ?
> >
> >[1]  https://issues.apache.org/jira/browse/IGNITE-12662
> >
> >--
> >
> >Best regards,
> >Alexei Scherbakov
> >
>
>
>
>
>
>
> ---
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> Please refer to https://www.db.com/disclosures for additional EU
> corporate and regulatory disclosures and to
> http://www.db.com/unitedkingdom/content/privacy.htm for information about
> privacy.
>

--

Best regards,
Alexei Scherbakov

[Sergey-A Kosarev]

Classification: Public

Alexey,
then I don't have objections.

-----Original Message-----
From: Alexei Scherbakov [mailto:[hidden email]]
Sent: 12 February 2020 12:01
To: dev <[hidden email]>
Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality

Sergey,

The ticket looks outdated.
In fact this is already implemented.

ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev <[hidden email]>:

> Classification: Public
>
> Hi, Alexey.
> I believe it can't be done until in-memory caches will use baseline
> topology [1].
> In our case we are using rebalanceDelay for in-memory caches.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8414
>
>
> Kind regards,
> Sergey Kosarev
>
> -----Original Message-----
> From: Zhenya Stanilovsky [mailto:[hidden email]]
> Sent: 12 February 2020 11:33
> To: [hidden email]
> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing
> functionality
>
>
>
> I know guys who use this setting (may be erroneously)  = MAX_INT for
> real rebalance delaying (very small sla) grid without persistence. But
> i don`t know further algo, may be if backup nodes  become extremely
> small they creates the same cluster near it. Can ignite simple disable rebalance?
>
> >Folks,
> >
> >I want to deprecate some obsolete functionality related to rebalancing.
> >Details in [1]
> >
> >Any objections ?
> >
> >[1]  https://issues.apache.org/jira/browse/IGNITE-12662
> >
> >--
> >
> >Best regards,
> >Alexei Scherbakov
> >
>
>
>
>
>
>
> ---
> This e-mail may contain confidential and/or privileged information. If
> you are not the intended recipient (or have received this e-mail in
> error) please notify the sender immediately and delete this e-mail.
> Any unauthorized copying, disclosure or distribution of the material
> in this e-mail is strictly forbidden.
>
> Please refer to https://www.db.com/disclosures for additional EU
> corporate and regulatory disclosures and to
> http://www.db.com/unitedkingdom/content/privacy.htm for information
> about privacy.
>

--

Best regards,
Alexei Scherbakov


---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

[Alexei Scherbakov]

Vyacheslav, Evgeny,

All scenarios where rebalanceDelay has meaning are handled by baseline
topology now.

ср, 12 февр. 2020 г. в 12:00, Alexei Scherbakov <
[hidden email]>:

> Sergey,
>
> The ticket looks outdated.
> In fact this is already implemented.
>
> ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev <[hidden email]>:
>
>> Classification: Public
>>
>> Hi, Alexey.
>> I believe it can't be done until in-memory caches will use baseline
>> topology [1].
>> In our case we are using rebalanceDelay for in-memory caches.
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-8414
>>
>>
>> Kind regards,
>> Sergey Kosarev
>>
>> -----Original Message-----
>> From: Zhenya Stanilovsky [mailto:[hidden email]]
>> Sent: 12 February 2020 11:33
>> To: [hidden email]
>> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing
>> functionality
>>
>>
>>
>> I know guys who use this setting (may be erroneously)  = MAX_INT for real
>> rebalance delaying (very small sla) grid without persistence. But i don`t
>> know further algo, may be if backup nodes  become extremely small they
>> creates the same cluster near it. Can ignite simple disable rebalance?
>>
>> >Folks,
>> >
>> >I want to deprecate some obsolete functionality related to rebalancing.
>> >Details in [1]
>> >
>> >Any objections ?
>> >
>> >[1]  https://issues.apache.org/jira/browse/IGNITE-12662
>> >
>> >--
>> >
>> >Best regards,
>> >Alexei Scherbakov
>> >
>>
>>
>>
>>
>>
>>
>> ---
>> This e-mail may contain confidential and/or privileged information. If
>> you are not the intended recipient (or have received this e-mail in error)
>> please notify the sender immediately and delete this e-mail. Any
>> unauthorized copying, disclosure or distribution of the material in this
>> e-mail is strictly forbidden.
>>
>> Please refer to https://www.db.com/disclosures for additional EU
>> corporate and regulatory disclosures and to
>> http://www.db.com/unitedkingdom/content/privacy.htm for information
>> about privacy.
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>

--

Best regards,
Alexei Scherbakov

[Zhenya Stanilovsky]

But baseline, it`s about persistence [1] isn`t it? I wrote about pure inmemory case.
 
[1] https://apacheignite.readme.io/docs/baseline-topology

>Vyacheslav, Evgeny,
>
>All scenarios where rebalanceDelay has meaning are handled by baseline
>topology now.
>
>ср, 12 февр. 2020 г. в 12:00, Alexei Scherbakov <
>[hidden email] >:
> 
>> Sergey,
>>
>> The ticket looks outdated.
>> In fact this is already implemented.
>>
>> ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev < [hidden email] >:
>>
>>> Classification: Public
>>>
>>> Hi, Alexey.
>>> I believe it can't be done until in-memory caches will use baseline
>>> topology [1].
>>> In our case we are using rebalanceDelay for in-memory caches.
>>>
>>> [1]  https://issues.apache.org/jira/browse/IGNITE-8414
>>>
>>>
>>> Kind regards,
>>> Sergey Kosarev
>>>
>>> -----Original Message-----
>>> From: Zhenya Stanilovsky [mailto:[hidden email]]
>>> Sent: 12 February 2020 11:33
>>> To:  [hidden email]
>>> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing
>>> functionality
>>>
>>>
>>>
>>> I know guys who use this setting (may be erroneously) = MAX_INT for real
>>> rebalance delaying (very small sla) grid without persistence. But i don`t
>>> know further algo, may be if backup nodes become extremely small they
>>> creates the same cluster near it. Can ignite simple disable rebalance?
>>>
>>> >Folks,
>>> >
>>> >I want to deprecate some obsolete functionality related to rebalancing.
>>> >Details in [1]
>>> >
>>> >Any objections ?
>>> >
>>> >[1]  https://issues.apache.org/jira/browse/IGNITE-12662
>>> >
>>> >--
>>> >
>>> >Best regards,
>>> >Alexei Scherbakov
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---
>>> This e-mail may contain confidential and/or privileged information. If
>>> you are not the intended recipient (or have received this e-mail in error)
>>> please notify the sender immediately and delete this e-mail. Any
>>> unauthorized copying, disclosure or distribution of the material in this
>>> e-mail is strictly forbidden.
>>>
>>> Please refer to  https://www.db.com/disclosures for additional EU
>>> corporate and regulatory disclosures and to
>>>  http://www.db.com/unitedkingdom/content/privacy.htm for information
>>> about privacy.
>>>
>>
>>
>> --
>>
>> Best regards,
>> Alexei Scherbakov
>>
>
>--
>
>Best regards,
>Alexei Scherbakov
> 

 
 
 
 

[Alexei Scherbakov]

No, baseline is supported for im-memory caches as well.

ср, 12 февр. 2020 г. в 12:18, Zhenya Stanilovsky <[hidden email]
>:

>
>
> But baseline, it`s about persistence [1] isn`t it? I wrote about
> pure inmemory case.
>
> [1] https://apacheignite.readme.io/docs/baseline-topology
> >Vyacheslav, Evgeny,
> >
> >All scenarios where rebalanceDelay has meaning are handled by baseline
> >topology now.
> >
> >ср, 12 февр. 2020 г. в 12:00, Alexei Scherbakov <
> >[hidden email] >:
> >
> >> Sergey,
> >>
> >> The ticket looks outdated.
> >> In fact this is already implemented.
> >>
> >> ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev <
> [hidden email] >:
> >>
> >>> Classification: Public
> >>>
> >>> Hi, Alexey.
> >>> I believe it can't be done until in-memory caches will use baseline
> >>> topology [1].
> >>> In our case we are using rebalanceDelay for in-memory caches.
> >>>
> >>> [1]  https://issues.apache.org/jira/browse/IGNITE-8414
> >>>
> >>>
> >>> Kind regards,
> >>> Sergey Kosarev
> >>>
> >>> -----Original Message-----
> >>> From: Zhenya Stanilovsky [mailto:[hidden email]]
> >>> Sent: 12 February 2020 11:33
> >>> To:  [hidden email]
> >>> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing
> >>> functionality
> >>>
> >>>
> >>>
> >>> I know guys who use this setting (may be erroneously) = MAX_INT for
> real
> >>> rebalance delaying (very small sla) grid without persistence. But i
> don`t
> >>> know further algo, may be if backup nodes become extremely small they
> >>> creates the same cluster near it. Can ignite simple disable rebalance?
> >>>
> >>> >Folks,
> >>> >
> >>> >I want to deprecate some obsolete functionality related to
> rebalancing.
> >>> >Details in [1]
> >>> >
> >>> >Any objections ?
> >>> >
> >>> >[1]  https://issues.apache.org/jira/browse/IGNITE-12662
> >>> >
> >>> >--
> >>> >
> >>> >Best regards,
> >>> >Alexei Scherbakov
> >>> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---
> >>> This e-mail may contain confidential and/or privileged information. If
> >>> you are not the intended recipient (or have received this e-mail in
> error)
> >>> please notify the sender immediately and delete this e-mail. Any
> >>> unauthorized copying, disclosure or distribution of the material in
> this
> >>> e-mail is strictly forbidden.
> >>>
> >>> Please refer to  https://www.db.com/disclosures for additional EU
> >>> corporate and regulatory disclosures and to
> >>>  http://www.db.com/unitedkingdom/content/privacy.htm for information
> >>> about privacy.
> >>>
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> Alexei Scherbakov
> >>
> >
> >--
> >
> >Best regards,
> >Alexei Scherbakov
> >
>
>
>
>

--

Best regards,
Alexei Scherbakov

[Zhenya Stanilovsky]

How can i understand it from documentation ?
 
If Ignite persistence is enabled, Ignite enforces the   baseline topology   concept which represents a set of server nodes in the cluster that will persist data on disk.
 

>No, baseline is supported for im-memory caches as well.
>
>ср, 12 февр. 2020 г. в 12:18, Zhenya Stanilovsky < [hidden email]
>>:
>
>>
>>
>> But baseline, it`s about persistence [1] isn`t it? I wrote about
>> pure inmemory case.
>>
>> [1]  https://apacheignite.readme.io/docs/baseline-topology
>> >Vyacheslav, Evgeny,
>> >
>> >All scenarios where rebalanceDelay has meaning are handled by baseline
>> >topology now.
>> >
>> >ср, 12 февр. 2020 г. в 12:00, Alexei Scherbakov <
>> > [hidden email] >:
>> >
>> >> Sergey,
>> >>
>> >> The ticket looks outdated.
>> >> In fact this is already implemented.
>> >>
>> >> ср, 12 февр. 2020 г. в 11:58, Sergey-A Kosarev <
>>  [hidden email] >:
>> >>
>> >>> Classification: Public
>> >>>
>> >>> Hi, Alexey.
>> >>> I believe it can't be done until in-memory caches will use baseline
>> >>> topology [1].
>> >>> In our case we are using rebalanceDelay for in-memory caches.
>> >>>
>> >>> [1]  https://issues.apache.org/jira/browse/IGNITE-8414
>> >>>
>> >>>
>> >>> Kind regards,
>> >>> Sergey Kosarev
>> >>>
>> >>> -----Original Message-----
>> >>> From: Zhenya Stanilovsky [mailto:[hidden email]]
>> >>> Sent: 12 February 2020 11:33
>> >>> To:  [hidden email]
>> >>> Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing
>> >>> functionality
>> >>>
>> >>>
>> >>>
>> >>> I know guys who use this setting (may be erroneously) = MAX_INT for
>> real
>> >>> rebalance delaying (very small sla) grid without persistence. But i
>> don`t
>> >>> know further algo, may be if backup nodes become extremely small they
>> >>> creates the same cluster near it. Can ignite simple disable rebalance?
>> >>>
>> >>> >Folks,
>> >>> >
>> >>> >I want to deprecate some obsolete functionality related to
>> rebalancing.
>> >>> >Details in [1]
>> >>> >
>> >>> >Any objections ?
>> >>> >
>> >>> >[1]  https://issues.apache.org/jira/browse/IGNITE-12662
>> >>> >
>> >>> >--
>> >>> >
>> >>> >Best regards,
>> >>> >Alexei Scherbakov
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ---
>> >>> This e-mail may contain confidential and/or privileged information. If
>> >>> you are not the intended recipient (or have received this e-mail in
>> error)
>> >>> please notify the sender immediately and delete this e-mail. Any
>> >>> unauthorized copying, disclosure or distribution of the material in
>> this
>> >>> e-mail is strictly forbidden.
>> >>>
>> >>> Please refer to  https://www.db.com/disclosures for additional EU
>> >>> corporate and regulatory disclosures and to
>> >>>  http://www.db.com/unitedkingdom/content/privacy.htm for information
>> >>> about privacy.
>> >>>
>> >>
>> >>
>> >> --
>> >>
>> >> Best regards,
>> >> Alexei Scherbakov
>> >>
>> >
>> >--
>> >
>> >Best regards,
>> >Alexei Scherbakov
>> >
>>
>>
>>
>>
>
>
>
>--
>
>Best regards,
>Alexei Scherbakov
> 

 
 
 
 

[Alexei Scherbakov]

V.Pyatkov

Doesn't rebalance topology solves it ?

ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:

> 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

[Alexei Scherbakov]

I've meant baseline topology.

ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov <
[hidden email]>:

>
> V.Pyatkov
>
> Doesn't rebalance topology solves it ?
>
> ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:
>
>> 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

[Maxim Muzafarov]

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
<[hidden email]> wrote:

>
> I've meant baseline topology.
>
> ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov <
> [hidden email]>:
>
> >
> > V.Pyatkov
> >
> > Doesn't rebalance topology solves it ?
> >
> > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:
> >
> >> 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

[Alexei Scherbakov]

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 <[hidden email]>:

> 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
> <[hidden email]> wrote:
> >
> > I've meant baseline topology.
> >
> > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov <
> > [hidden email]>:
> >
> > >
> > > V.Pyatkov
> > >
> > > Doesn't rebalance topology solves it ?
> > >
> > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:
> > >
> > >> 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

[Maxim Muzafarov]

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
<[hidden email]> 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 <[hidden email]>:
>
> > 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
> > <[hidden email]> wrote:
> > >
> > > I've meant baseline topology.
> > >
> > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov <
> > > [hidden email]>:
> > >
> > > >
> > > > V.Pyatkov
> > > >
> > > > Doesn't rebalance topology solves it ?
> > > >
> > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:
> > > >
> > > >> 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

[Alexei Scherbakov]

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 <[hidden email]>:

> 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
> <[hidden email]> 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 <[hidden email]>:
> >
> > > 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
> > > <[hidden email]> wrote:
> > > >
> > > > I've meant baseline topology.
> > > >
> > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov <
> > > > [hidden email]>:
> > > >
> > > > >
> > > > > V.Pyatkov
> > > > >
> > > > > Doesn't rebalance topology solves it ?
> > > > >
> > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:
> > > > >
> > > > >> 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

[Ivan Rakov]

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 <
[hidden email]> 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 <[hidden email]>:
>
> > 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
> > <[hidden email]> 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 <[hidden email]>:
> > >
> > > > 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
> > > > <[hidden email]> wrote:
> > > > >
> > > > > I've meant baseline topology.
> > > > >
> > > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov <
> > > > > [hidden email]>:
> > > > >
> > > > > >
> > > > > > V.Pyatkov
> > > > > >
> > > > > > Doesn't rebalance topology solves it ?
> > > > > >
> > > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:
> > > > > >
> > > > > >> 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
>

[Pavel Pereslegin]

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 <[hidden email]>:

>
> 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 <
> [hidden email]> 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 <[hidden email]>:
> >
> > > 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
> > > <[hidden email]> 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 <[hidden email]>:
> > > >
> > > > > 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
> > > > > <[hidden email]> wrote:
> > > > > >
> > > > > > I've meant baseline topology.
> > > > > >
> > > > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov <
> > > > > > [hidden email]>:
> > > > > >
> > > > > > >
> > > > > > > V.Pyatkov
> > > > > > >
> > > > > > > Doesn't rebalance topology solves it ?
> > > > > > >
> > > > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:
> > > > > > >
> > > > > > >> 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
> >

[Pavel Pereslegin]

> +1 to deprecate rebalanceOrder and remove related functionality,
Meant to "rework related functionality" not "remove".

чт, 13 февр. 2020 г. в 12:47, Pavel Pereslegin <[hidden email]>:

>
> 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 <[hidden email]>:
> >
> > 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 <
> > [hidden email]> 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 <[hidden email]>:
> > >
> > > > 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
> > > > <[hidden email]> 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 <[hidden email]>:
> > > > >
> > > > > > 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
> > > > > > <[hidden email]> wrote:
> > > > > > >
> > > > > > > I've meant baseline topology.
> > > > > > >
> > > > > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov <
> > > > > > > [hidden email]>:
> > > > > > >
> > > > > > > >
> > > > > > > > V.Pyatkov
> > > > > > > >
> > > > > > > > Doesn't rebalance topology solves it ?
> > > > > > > >
> > > > > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov <[hidden email]>:
> > > > > > > >
> > > > > > > >> 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
> > >