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