[ 
https://issues.apache.org/jira/browse/CASSANDRA-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13003946#comment-13003946
 ] 

Terje Marthinussen commented on CASSANDRA-2282:
-----------------------------------------------

>From ReadCallback.java


        this.endpoints = repair || resolver instanceof RowRepairResolver
                       ? endpoints
                       : endpoints.subList(0, Math.min(endpoints.size(), 
blockfor)); // min so as to not throw exception until assureSufficient is called

This will cut the list of endpoints to whatever is the consistency requirement 
(in the case where repair is false, which for instance happens all the time for 
a rangescan).

Later:
assert resolver.getMessageCount() <= endpoints.size()

which will cause an assert if all nodes answers on a range request (or if you 
have a random readrepair).

I am actually not 100% sure what the fix is right now as I have not had time to 
scan the rest of the code and need to leave office for today, but that is the 
problem anyway :)
To be honest, the logic here may look a bit broken.

The assert happening here may good either. The error condition is not returned 
to the client, so it will hang around waiting for a timeout to occur.
Maybe the code should throw some exception before the assert?

Something like
assert resolver.getMessageCount() <= endpoints.size() :  "Got " + 
resolver.getMessageCount() + " replies but only know " + endpoints.size() + " 
endpoints";
may also be good?

> ReadCallback AssertionError: resolver.getMessageCount() <= endpoints.size()
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-2282
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2282
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.3
>            Reporter: Tyler Hobbs
>
> In a three node cluster with RF=2, when trying to page through all rows with 
> get_range_slices() at CL.ONE, I get timeouts on the client side.  Looking at 
> the Cassandra logs, all of the nodes show the following AssertionError 
> repeatedly:
> {noformat}
> ERROR [RequestResponseStage:2] 2011-03-07 19:10:27,527 
> DebuggableThreadPoolExecutor.java (line 103) Error in ThreadPoolExecutor
> java.lang.AssertionError
>         at 
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
>         at 
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
>         at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
>         at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>         at java.lang.Thread.run(Thread.java:636)
> ERROR [RequestResponseStage:2] 2011-03-07 19:10:27,529 
> AbstractCassandraDaemon.java (line 114) Fatal exception in thread 
> Thread[RequestResponseStage:2,5,main]
> java.lang.AssertionError
>         at 
> org.apache.cassandra.service.ReadCallback.response(ReadCallback.java:127)
>         at 
> org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:49)
>         at 
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
>         at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>         at java.lang.Thread.run(Thread.java:636)
> {noformat}
> The nodes are all running 0.7.3.  The cluster was at size 3 before any data 
> was inserted, and everything else appears perfectly healthy.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to