[
https://issues.apache.org/jira/browse/CASSANDRA-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-2069:
--------------------------------------
Attachment: 2069-v2.txt
v2 adds a READ_REPAIR stage and does resolve of digests that were not checked
for the client result on that stage as soon as response() collects all the
replies. If there is a mismatch and we do a re-read of full
resultset, we also check those results on the RR stage based on response() (in
AsyncRepairRunner, now in ReadCallback.)
I preserved the feature from v1 of not doing repairs if the RR stage is full.
Most of the code changes are about getting the right information into
ReadCallback (e.g. endpoints) and some ceremony to make static typing happy
(IReadCallback).
A side benefit is that StorageProxy.fetchRows is significantly cleaner (no more
commandEndpoints or repairs collections).
> Read repair causes tremendous GC pressure
> -----------------------------------------
>
> Key: CASSANDRA-2069
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2069
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.7.1
> Reporter: Brandon Williams
> Assignee: Jonathan Ellis
> Fix For: 0.7.2
>
> Attachments: 2069-v2.txt, 2069.txt
>
>
> To reproduce: start a three node cluster, insert 1M rows with stress.java and
> rf=2. Take one down, delete its data, then bring it back up and issue 1M
> reads against it. After the run is done you will see at least 1 STW long
> enough to mark the node as dead, often 4 or 5.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
