[
https://issues.apache.org/jira/browse/CASSANDRA-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-2552:
--------------------------------
Attachment: ResolveRaceTest.java
Here is a cut down testcase that reproduces the race: it looks like two threads
can race on step 2 such that they neither accounts for the item added by the
other, and both think the set of responses is too small.
I have a patch that makes append + size an atomic operation: I'll post it as
soon as I clean it up a bit.
> ReadResponseResolver Race
> -------------------------
>
> Key: CASSANDRA-2552
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2552
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Stu Hood
> Assignee: Stu Hood
> Fix For: 0.8.0
>
> Attachments: ResolveRaceTest.java
>
>
> 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
> ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
> in 2 messages
> INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514
> ReadResponseResolver.java (line 87) post append for 1087367065: hasData=true
> in 1 messages
> INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
> Read timeout: java.util.concurrent.TimeoutException:
> ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
> {noformat}
> The last line shows that both results were present, and that one of them was
> holding data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
