You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Romain Hardouin (JIRA)" <ji...@apache.org> on 2017/01/11 10:03:58 UTC
[jira] [Comment Edited] (CASSANDRA-13115) Read repair is not
blocking repair to finish in foreground repair
[ https://issues.apache.org/jira/browse/CASSANDRA-13115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15817856#comment-15817856 ]
Romain Hardouin edited comment on CASSANDRA-13115 at 1/11/17 10:03 AM:
-----------------------------------------------------------------------
I don't understand why you say it violates quorum reads, with RF=2 {{QUORUM == 2}} i.e. like {{ALL}}.
But you read with {{ONE / LOCAL_ONE}} when doing {{7. query some data from node1}}, don't you?
bq. This should trigger read repair.
Background read repair because of CL {{ONE}}, right?
Did you set {{dclocal_read_repair_chance/read_repair_chance = 1.0}}?
was (Author: rha):
I don't understand why you say it violates quorum reads, with RF=2 {{QUORUM == 2}} i.e. like {{ALL}}.
You read with {{ONE / LOCAL_ONE}} when doing {{7. query some data from node1}}, don't you?
bq. This should trigger read repair.
Did you set {{dclocal_read_repair_chance/read_repair_chance = 1.0}}?
> Read repair is not blocking repair to finish in foreground repair
> -----------------------------------------------------------------
>
> Key: CASSANDRA-13115
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13115
> Project: Cassandra
> Issue Type: Bug
> Environment: ccm on OSX
> Reporter: Xiaolong Jiang
>
> The code trying to wait(block) for repair result to come back in 3.X is below:
> {code:title= DataResolver.java|borderStyle=solid}
> public void close()
> {
> try
> {
> FBUtilities.waitOnFutures(repairResults, DatabaseDescriptor.getWriteRpcTimeout());
> }
> catch (TimeoutException ex)
> {
> // We got all responses, but timed out while repairing
> int blockFor = consistency.blockFor(keyspace);
> if (Tracing.isTracing())
> Tracing.trace("Timed out while read-repairing after receiving all {} data and digest responses", blockFor);
> else
> logger.debug("Timeout while read-repairing after receiving all {} data and digest responses", blockFor);
> throw new ReadTimeoutException(consistency, blockFor-1, blockFor, true);
> }
> }
> {code}
> in DataResolver class, but this close method is never called and it's also not auto close(RepairMergeListener is not extending from AutoCloseable/CloseableIterator) which means we never wait for repair to finish before returning final result.
> The steps to reproduce:
> 1. create some keyspace/table with RF = 2
> 2. start 2 nodes using ccm
> 3. stop node2
> 4. disable node1 hinted hand off
> 5. write some data to node1 with consistency level one
> 6. start node2
> 7. query some data from node1
> This should trigger read repair. I put some log in above close method, and can not see log print put.
> So this bug will basically violate "monotonic quorum reads " guarantee.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)