[
https://issues.apache.org/jira/browse/GEODE-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14623148#comment-14623148
]
ASF subversion and git services commented on GEODE-74:
------------------------------------------------------
Commit 3d94467231c9f71368b02fb952ae2b2835fdedff in incubator-geode's branch
refs/heads/feature/GEODE-74 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=3d94467 ]
GEODE-74: Making the satisfy redundancy phase of rebalance parallel
Tasks submitted to background threads to trigger redundancy
satisfaction. After the satisfy redundancy phase is done we wait for the
tasks to finish.
The number of buckets that can be recovering in parallel is controlled
by the system property gemfire.MAX_PARALLEL_BUCKET_RECOVERIES, currently
set to 8.
If a redundancy recovery/rebalance is restarted due to a membership
change, wait for any in progress operations to complete before fetching
new information from all of the members.
> Recover redundancy in parallel
> ------------------------------
>
> Key: GEODE-74
> URL: https://issues.apache.org/jira/browse/GEODE-74
> Project: Geode
> Issue Type: Improvement
> Components: core
> Reporter: Dan Smith
> Assignee: Dan Smith
> Priority: Minor
>
> When redundancy recovery happens in geode, a single member coordinates the
> recovery, choosing the best targets and directing each member to create a
> redundant bucket.
> The rebalancing coordinator node directs the creation of each bucket
> serially. When multiple members are started simultaneously, it should be
> possible to recover redundancy more quickly by having them work in parallel.
> The proposal here is to still have a single coordinator, but the coordinator
> will put tasks into a threadpool to recover buckets asynchronously.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
