You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Marcus Eriksson (JIRA)" <ji...@apache.org> on 2014/11/04 14:49:34 UTC

[jira] [Commented] (CASSANDRA-8208) Inconsistent failure handling with repair

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

Marcus Eriksson commented on CASSANDRA-8208:
--------------------------------------------

I think this makes us run anticompaction even if one of the sessions fail.

Looks like we just left the parent repair sessions around if we failed before as well, we should probably add a flag to the AnticompactionRequest message that we send out in ARS#finishParentSession that says whether or not we were actually successful

> Inconsistent failure handling with repair
> -----------------------------------------
>
>                 Key: CASSANDRA-8208
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8208
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Marcus Eriksson
>            Assignee: Yuki Morishita
>             Fix For: 3.0
>
>         Attachments: 8208.txt
>
>
> I think we introduced this with CASSANDRA-6455, problem is that we now treat all repair futures as a single unit (Futures.allAsList(..)) which makes the whole thing fail if one sub-future fails. Also, when one of those fail, we notify nodetool that we failed and we stop the executor with shutdownNow() which throws out any pending RepairJobs.
> [~yukim] I think we used to be able to proceed with the other RepairSessions even if one fails, right? If not, we should probably call cancel on the RepairJob runnables which are in queue for the executor after calling shutdownNow() in repairComplete() in StorageService. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)