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