Mailing-List: contact cassandra-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Message-ID: <1130153612.111891265590768123.JavaMail.jira@brutus.apache.org>
Date: Mon, 8 Feb 2010 00:59:28 +0000 (UTC)
From: "Stu Hood (JIRA)" <jira@apache.org>
To: cassandra-commits@incubator.apache.org
Subject: [jira] Updated: (CASSANDRA-762) Load balancing does not account for
 the load of the moving node
In-Reply-To: <1648441837.17681265239287860.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stu Hood updated CASSANDRA-762:
-------------------------------

    Attachment: for-0.5-0001-Wait-BROADCAST_INTERVAL-for-load-information-and-cal.patch

Here is a rebased copy of the patch for 0.5. Because 0.5 is still stat'ing files, it doesn't lower the BROADCAST_INTERVAL, although we may want to.

> Load balancing does not account for the load of the moving node
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-762
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-762
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.5, 0.6
>            Reporter: Stu Hood
>            Assignee: Stu Hood
>            Priority: Minor
>             Fix For: 0.5, 0.6
>
>         Attachments: 0001-Wait-BROADCAST_INTERVAL-for-load-information-and-cal.patch, for-0.5-0001-Wait-BROADCAST_INTERVAL-for-load-information-and-cal.patch
>
>
> Given a node A (with load 10 gb) and a node B (with load 20 gb), running the loadbalance command against node A will:
> 1. Remove node A from the ring
>   * Recalculates pending ranges so that node B is responsible for the entire ring
> 2. Pick the most loaded node
>   * node B is still reporting 20 gb load, because that is all it has locally
> 3. Choose a token that divides the range of the most loaded node in half
> Since the token calculation doesn't take into account the load that node B is 'inheriting' from node A, the token will divide node B's load in half and swap the loads. Instead, the token calculation needs to pretend that B has already inherited the 10 gb from node A, for a total of 30 gb. The token that should be chosen falls at 15 gb of the total load, or 5 gb into node B's load.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.