[
https://issues.apache.org/jira/browse/CASSANDRA-14918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16708039#comment-16708039
]
Jason Harvey commented on CASSANDRA-14918:
------------------------------------------
The patch included in CASSANDRA-14812 does appear to fix my symptom!
> multiget_slice returning inconsistent results when performed with CL higher
> than ONE
> ------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14918
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
> Environment: 9 node ring, cassandra 3.11.2, RF of 3.
> Ring is not upgraded from any previous version.
> Reporter: Jason Harvey
> Priority: Major
>
> I'm on cassandra 3.11.2. On a number of CFs I'm observing that multiget_slice
> sometimes returns inconsistent, partially-empty results for the exact same
> request, despite the underlying data not changing. This behaviour is only
> observed when I perform the multiget with a CL higher than `ONE` - all `ONE`
> requests work as expected.
> I was able to create a test table in a lab environment and after fiddling
> with the data enough was able to repro. I was unable to perform a very basic
> repro with only a few rows present. To repro, I inserted a couple million
> rows, deleted a subset of those rows, and the performed a multiget slice on a
> list of partitions which included living and deleted partitions. The result
> is that sometimes, when performing a multiget on this data, I get a thrift
> struct back with partition info, but no column names or values - the thrift
> LIST that is generated contains 0 elements. If I issue this exact same
> request 5 times I might get the appropriate data back once or twice. I have
> verified on the wire that the request being made is identical - only the
> results are different.
> The repro case described above is rather meandering so I'm working to break
> it down into a simple of a case as I can. It is unclear if deletions need to
> occur to reproduce this or not.
> Edit: Just confirmed I'm observing this behaviour on multiple distinct 3.11.2
> rings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
