cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Updated: (CASSANDRA-2069) Read repair causes tremendous GC pressure
Date Fri, 04 Feb 2011 06:04:22 GMT


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:
>             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 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:


View raw message