You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jason Harvey (JIRA)" <ji...@apache.org> on 2018/12/08 07:30:00 UTC
[jira] [Resolved] (CASSANDRA-14918) multiget_slice returning
inconsistent results when performed with CL higher than ONE
[ https://issues.apache.org/jira/browse/CASSANDRA-14918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Harvey resolved CASSANDRA-14918.
--------------------------------------
Resolution: Duplicate
> 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: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org