Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 13 Sep 2011 08:02:08 +0000 (UTC)
From: "Anton Winter (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1431934396.21220.1315900928942.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (CASSANDRA-3194) repair streaming forwarding loop
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

repair streaming forwarding loop
--------------------------------

                 Key: CASSANDRA-3194
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3194
             Project: Cassandra
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.0.0
            Reporter: Anton Winter


I am able to reproduce what appears to be a streaming forwarding loop when running repairs.  This affect only nodes using broadcast_address (ec2 external ip) & listen_address of 0.0.0.0. (Configuration is using property file snitch in a multi DC NTS where some DC's are EC2 and others are not).  The hosts in the other dc's not using broadcast_address do not experience this symptom.

on ec2 host dc1host1:
INFO [AntiEntropyStage:1] 2011-09-13 06:34:01,673 StreamingRepairTask.java (line 211) [streaming task #ce793c30-ddd1-11e0-0000-071a4b76fefb] Received task from /0.0.0.0 to stream 12259 ranges to /external.ec2.ip.dc1host3
 INFO [AntiEntropyStage:1] 2011-09-13 06:34:01,673 StreamingRepairTask.java (line 136) [streaming task #ce793c30-ddd1-11e0-0000-071a4b76fefb] Forwarding streaming repair of 12259 ranges to /external.ec2.ip.of.dc1host1 (to be streamed with /external.ip.of.host3)

The above appears to trigger another streaming task and results in saturating the network interfaces dc1host1.  The above log entries are repeated until cassandra is killed.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira