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

Yuki Morishita commented on CASSANDRA-8208:
-------------------------------------------

Pushed v2 to https://github.com/yukim/cassandra/commits/8208-2
which contains CASSANDRA-8291 also.

This time I changed AnticompactionRequest to send successful repair ranges, so 
that anticompaction runs only on those ranges.
If there is no successful repair, then just skips anticompaction.


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

Reply via email to