[
https://issues.apache.org/jira/browse/CASSANDRA-11696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15345996#comment-15345996
]
Joel Knighton commented on CASSANDRA-11696:
-------------------------------------------
+1.
All your testall/dtest runs looked clean with the exception of dtests on trunk.
Trunk had some known flaky failures and failures on four tests that were not
tagged as flaky. Some of these have failed on trunk recently - the failures
looked like [CASSANDRA-12072] and all seemed related to timeouts on driver
connections/cluster setup, so I'm not too concerned. They all passed locally. I
triggered one more trunk dtest run - this time, two different tests failed in
comparable ways, so I'm pretty sure it is part of some larger environmental
problem. Again, the untagged failing tests passed locally. I'm comfortable with
these test results.
> Incremental repairs can mark too many ranges as repaired
> --------------------------------------------------------
>
> Key: CASSANDRA-11696
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11696
> Project: Cassandra
> Issue Type: Bug
> Reporter: Joel Knighton
> Assignee: Marcus Eriksson
> Priority: Critical
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> Incremental repairs are tracked using a parent session - a subordinate repair
> session is created for each range in the repair. When a node participating in
> the repair receives a validation request, it will reference the sstables in
> the parent repair session. When all subordinate sessions conclude, each node
> anticompacts SSTables based on the parent repair session for the whole range
> of the repair, but these referenced SSTables may have only been present for
> the validation of some subset of the ranges because the SSTables were created
> concurrent with the parent repair session.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
