geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-74) Recover redundancy in parallel
Date Tue, 14 Jul 2015 21:23:05 GMT


ASF subversion and git services commented on GEODE-74:

Commit 9fa9ced08f1851f97d2d2407f1519dcc3cac06e0 in incubator-geode's branch refs/heads/feature/GEODE-56
from [~upthewaterspout]
[;h=9fa9ced ]

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:
>             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

View raw message