You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "siddharth verma (JIRA)" <ji...@apache.org> on 2016/04/28 09:58:12 UTC
[jira] [Created] (CASSANDRA-11680) Inconsistent data while paging
through a table
siddharth verma created CASSANDRA-11680:
-------------------------------------------
Summary: Inconsistent data while paging through a table
Key: CASSANDRA-11680
URL: https://issues.apache.org/jira/browse/CASSANDRA-11680
Project: Cassandra
Issue Type: Bug
Reporter: siddharth verma
We have the following table structure:
CREATE TABLE keyspace.book_properties (
book_id text,
group_id bigint,
property_display_name text,
created timestamp,
property_name text,
property_uuid uuid,
property_value text,
updated timestamp,
PRIMARY KEY (book_id, group_id, property_display_name)
) WITH CLUSTERING ORDER BY (group_id ASC, property_display_name ASC);
We have lucene indexes on group_id, property_display_name, created, property_name, property_uuid, updated
When we run a full table scan. Below is the sample code snippet
boundStatement = new BoundStatement(session.prepare("select * from keyspace.book_properties");
boundStatement.setConsistencyLevel(ConsistencyLevel.ALL);
boundStatement.setFetchSize(fetchSize);
PagingState currentPageInfo = null;
do {
try {
if (currentPageInfo != null)
{ boundStatement.setPagingState(currentPageInfo); }
ResultSet rs = session.execute(boundStatement);
processResultSet(rs);
currentPageInfo = rs.getExecutionInfo().getPagingState();
} catch (NoHostAvailableException e) {
}
} while (currentPageInfo != null);
......
processResultSet(ResultSet rs){
int remaining = rs.getAvailableWithoutFetching();
if (remaining != 0) {
for (Row row : rs) {
processCassandraRow(row);
if (--remaining == 0)
{ break; }
}
}
}
Many a time, we got corrupted data in this process.
1. property_uuid was returned as null in many cases, when actual data had a value for it.
2. returned value for property_uuid in table scan was different from property_uuid as seen from cqlsh
3. returned value for group_id in table scan was different from group_id as seen from cqlsh
book_properties has around 140 million records.
book_properties has heavy read, write and update requests while paging is in process
Cassandra version dsc3.0.3
Side Note:
For one of the inconsistent column, we specifically checked the writetime(..) to make sure data hadn't been changed while the job was in process. This was not the case
checked for case 2 : select property_uuid, writetime(property_uuid) from book_properties where book_id = 'BOOK31263786';
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)