[
https://issues.apache.org/jira/browse/IGNITE-12093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16913005#comment-16913005
]
Anton Vinogradov commented on IGNITE-12093:
-------------------------------------------
[~ascherbakov],
Thanks for the tip!
I see following workarounds here:
1) Have some throttle limiter in case of concurrent updates.
But, I don't like this case, because it's a buggy by design.
2) Change rebalance logiŃ to 2-phase way
- phase one is a rebalance without any concurrent updates (partition should not
be marked as moving at this phase to avoid concurrent updates attempts)
- phase two is a historical rebalance (of updates happened during phase one)
This case has a convergence issue by design, historical rebalance can be so
huge that it will be faster to rebalance without this feature.
3) Change logic to confirm concurrent updates during the rebalance immediately
(any consistency leak here?), collect them at in-memory ordered WAL analog
(linkedQueue) and apply them like historical rebalance messages in a batch way.
Once queue becomes empty we'll able to switch to regular update requests
handling and own the partition safe.
Same optimization we're planned to have at file rebalance (IGNITE-8020)
sometime.
Seems, the third case is the best :)
> Initial rebalance should be performed as efficiently as possible
> ----------------------------------------------------------------
>
> Key: IGNITE-12093
> URL: https://issues.apache.org/jira/browse/IGNITE-12093
> Project: Ignite
> Issue Type: Task
> Reporter: Anton Vinogradov
> Priority: Major
> Labels: iep-16
>
> {{rebalanceThreadPoolSize}} setting should be ignored on initial rebalance
> for demanders.
> Maximum suitable thread pool size should be used during the initial rebalance
> to perform it asap.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
