cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2552) ReadResponseResolver Race
Date Wed, 27 Apr 2011 16:39:03 GMT


Jonathan Ellis commented on CASSANDRA-2552:

bq. Wouldn't it be similar complexity (one O(N) operation per message received) to keep NBHM
and implement getMessageCount as an iterate-entries operation?

We can actually do size-by-iteration for basically free (with a little refactoring), since
we're already iterating for isDataPresent. We can just push the iteration into the callers
who care about size-and-data-present and do it with one loop.

But if I am honest that is premature optimization.  We are already using the AtomicInteger
approach in DatacenterReadCallback.  I'll submit a patch to standardize on that.

> ReadResponseResolver Race
> -------------------------
>                 Key: CASSANDRA-2552
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Stu Hood
>            Assignee: Stu Hood
>             Fix For: 0.8.0
>         Attachments: 0001-Move-Resolvers-to-atomic-append-count.txt,
> When receiving a response, ReadResponseResolver uses a 3 step process to decide whether
to trigger the condition that enough responses have arrived:
> # Add new response
> # Check response set size
> # Check that data is present
> I think that these steps must have been reordered by the compiler in some cases, because
I was able to reproduce a case for a QUORUM read where the condition is not properly triggered:
> {noformat}
> INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514 (line
87) post append for 1087367065: hasData=false in 2 messages
> INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514 (line
87) post append for 1087367065: hasData=true in 1 messages
> INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 (line 623) Read timeout:
java.util.concurrent.TimeoutException: ReadResponseResolver@1087367065(/,/,)
> {noformat}
> The last line shows that both results were present, and that one of them was holding

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message