Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 3 Jun 2013 13:36:22 +0000 (UTC)
From: "Jason Brown (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12640653.1365031123445.56356.1370266582079@arcas>
In-Reply-To: <JIRA.12640653.1365031123445@arcas>
References: <JIRA.12640653.1365031123445@arcas>
Subject: [jira] [Commented] (CASSANDRA-5426) Redesign repair messages
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-5426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13673105#comment-13673105 ] 

Jason Brown commented on CASSANDRA-5426:
----------------------------------------

In StreamingRepairTask.initiateStreaming(), there's this block

{code}try
{
...
  StreamOut.transferSSTables(outsession, sstables, request.ranges, OperationType.AES);
  // request ranges from the remote node
  StreamIn.requestRanges(request.dst, desc.keyspace, Collections.singleton(cfstore), request.ranges, this, OperationType.AES);
}
catch(Exception e) ...{code}

Is there any value in putting the StreamIn.requestRanges() in a separate try block and not (immediately) fail if StreamOut has a problem? Then, we could potentially make some forward progress (for the stream StreamIn) even if StreamOut fails? I'll note that 1.2 has the same try/catch as Yuki's new work, so it has not changed in that regard.


> Redesign repair messages
> ------------------------
>
>                 Key: CASSANDRA-5426
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5426
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Yuki Morishita
>            Assignee: Yuki Morishita
>            Priority: Minor
>              Labels: repair
>             Fix For: 2.0
>
>
> Many people have been reporting 'repair hang' when something goes wrong.
> Two major causes of hang are 1) validation failure and 2) streaming failure.
> Currently, when those failures happen, the failed node would not respond back to the repair initiator.
> The goal of this ticket is to redesign message flows around repair so that repair never hang.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira