[
https://issues.apache.org/jira/browse/CASSANDRA-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-937:
-------------------------------------
Attachment: 937-2.txt
Repair is always invoked by a node that has a copy of the data, or thinks it
should (that is how it gets the "initial row" to compare digests against), but
if the definition of who should have replicas changes either from bootstrap or
during rebuilding of the ring after a cluster restart then local node could be
an "extra" replica at repair time.
This patch changes repair to keep the replica set constant throughout the
process. It also fixes repair to start comparing digests immediately rather
than waiting for all responses first for no reason, and avoids an extra read
from the local replica, re-using the one that we've been comparing digests with.
> Invalid Response count 4
> ------------------------
>
> Key: CASSANDRA-937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-937
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: replication factor is set to 3
> Reporter: Dan Di Spaltro
> Fix For: 0.6.1
>
> Attachments: 937-2.txt
>
>
> 2010-03-30_21:59:04.64973 ERROR - Error in ThreadPoolExecutor
> 2010-03-30_21:59:04.64973 java.lang.AssertionError: invalid response count 4
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.service.ReadResponseResolver.<init>(ReadResponseResolver.java:54)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.service.ConsistencyManager$DigestResponseHandler.doReadRepair(ConsistencyManager.java:89)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.service.ConsistencyManager$DigestResponseHandler.handleDigestResponses(ConsistencyManager.java:75)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.service.ConsistencyManager$DigestResponseHandler.response(ConsistencyManager.java:60)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:35)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:40)
> 2010-03-30_21:59:04.64973 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 2010-03-30_21:59:04.64973 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 2010-03-30_21:59:04.64973 at java.lang.Thread.run(Thread.java:636)
> 2010-03-30_21:59:04.64973 ERROR - Fatal exception in thread
> Thread[RESPONSE-STAGE:5,5,main]
> 2010-03-30_21:59:04.64973 java.lang.AssertionError: invalid response count 4
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.service.ReadResponseResolver.<init>(ReadResponseResolver.java:54)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.service.ConsistencyManager$DigestResponseHandler.doReadRepair(ConsistencyManager.java:89)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.service.ConsistencyManager$DigestResponseHandler.handleDigestResponses(ConsistencyManager.java:75)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.service.ConsistencyManager$DigestResponseHandler.response(ConsistencyManager.java:60)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:35)
> 2010-03-30_21:59:04.64973 at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:40)
> 2010-03-30_21:59:04.64973 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> 2010-03-30_21:59:04.64973 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> 2010-03-30_21:59:04.64973 at java.lang.Thread.run(Thread.java:636)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
