Hello Maxim,
> Properties are not too important and we can remove unnecessary
> functionality reflecting them even, for 2.8 -> 2.9 releases for instance.
IMHO, we should preserve source, binary and behavioral compatibility.
Removing methods from public API may break all these requirements.
> As
Slava,
I don't know the right answer to this case, but I think what exactly
compatibility is important:
1. PDS compatibility
2. Messaging compatibility
3. Rolling upgrades
4. Compile application on newer 2.x version
Properties are not too important and we can remove unnecessary
functionality ref
Hello Maxim,
In general, we should not remove existing public APIs / properties until
the major version is released, even though the community has an agreement
that these properties are useless.
I fully support the idea that rebalanceOrder, rebalanceDelay, and
CacheRebalanceMode#NONE should be mar
Folks,
Can we not only mark `rebalanceDelay` and `rebalanceOrder` with
@deprecated annotation but also remove its support from the source
code? For instance, for the next 2.9 release. I see the next
advantages here:
1. It will greatly simplify the implementation of ExchageManager (It
also overco
Folks,
Looks like we came to an agreement - rebalanceDelay and rebalanceOrder
should be deprecated.
Anyone else has objections ?
чт, 13 февр. 2020 г. в 14:40, Alexei Scherbakov <
alexey.scherbak...@gmail.com>:
> But in combination with BLT it will work as intended - no rebalancing
> under the
But in combination with BLT it will work as intended - no rebalancing under
the cover.
чт, 13 февр. 2020 г. в 14:39, Alexei Scherbakov <
alexey.scherbak...@gmail.com>:
> Of course, stable topology will be just a hint.
>
> Any node can leave at any moment.
>
> чт, 13 февр. 2020 г. в 14:35, Alexei
Of course, stable topology will be just a hint.
Any node can leave at any moment.
чт, 13 февр. 2020 г. в 14:35, Alexei Scherbakov <
alexey.scherbak...@gmail.com>:
> 1. Yes
>
> 2. This is right but doesn't sound like a bug. The rebalancing will be
> finished before releasing syncFut and partition
1. Yes
2. This is right but doesn't sound like a bug. The rebalancing will be
finished before releasing syncFut and partitions will contain all necessary
data (but are still in moving state).
3. No, local node doesn't wait the rebalancing on all grid nodes.
Actually, I think SYNC mode should be
Pavel,
It's still a big question regarding SYNC rebalance mode. Here is my thoughts.
1. Yes, we must rebalance such caches prior to ASYNC one (if the
rebalanceOrder configuration will be removed).
2. When persistence is enabled and when WAL is disabled (on the first
rebalance start), I think we
> +1 to deprecate rebalanceOrder and remove related functionality,
Meant to "rework related functionality" not "remove".
чт, 13 февр. 2020 г. в 12:47, Pavel Pereslegin :
>
> Hello,
>
> +1 to deprecate rebalanceOrder and remove related functionality,
> should we create a separate ticket for this?
>
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 part
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
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
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
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 wou
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
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 :
>
>> Hi,
>>
>> I am sure we can to reduce this ability, but do not completely.
>> W
V.Pyatkov
Doesn't rebalance topology solves it ?
ср, 12 февр. 2020 г. в 12:31, 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 helpf
s.
>> >>>
>> >>> [1] https://issues.apache.org/jira/browse/IGNITE-8414
>> >>>
>> >>>
>> >>> Kind regards,
>> >>> Sergey Kosarev
>> >>>
>> >>> -Original Message-
>> >>&
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://apa
> >>>
> >>>
> >>> Kind regards,
> >>> Sergey Kosarev
> >>>
> >>> -Original Message-
> >>> From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID]
> >>> Sent: 12 February 2020 11:33
> >>&g
ps://issues.apache.org/jira/browse/IGNITE-8414
>>>
>>>
>>> Kind regards,
>>> Sergey Kosarev
>>>
>>> -Original Message-
>>> From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID]
>>> Sent: 12 February 2020 11:33
>>>
gt;
>> [1] https://issues.apache.org/jira/browse/IGNITE-8414
>>
>>
>> Kind regards,
>> Sergey Kosarev
>>
>> -Original Message-
>> From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID]
>> Sent: 12 February 2020 11:33
>> To: dev@ig
Classification: Public
Alexey,
then I don't have objections.
-Original Message-
From: Alexei Scherbakov [mailto:alexey.scherbak...@gmail.com]
Sent: 12 February 2020 12:01
To: dev
Subject: Re: [DISCUSSION] Deprecation of obsolete rebalancing functionality
Sergey,
The ticket
gt; To: dev@ignite.apache.org
> 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, m
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
ssage-
From: Zhenya Stanilovsky [mailto:arzamas...@mail.ru.INVALID]
Sent: 12 February 2020 11:33
To: dev@ignite.apache.org
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
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?
>F
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
29 matches
Mail list logo
