cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8208) Inconsistent failure handling with repair
Date Thu, 13 Nov 2014 13:43:35 GMT

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

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

+1

Small nit; we only use 'range' in RepairSessionResult so I guess we could skip introducing
that class, but it might also make it clearer, so totally fine to leave it in.

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

Mime
View raw message