[
https://issues.apache.org/jira/browse/CASSANDRA-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sylvain Lebresne updated CASSANDRA-2653:
----------------------------------------
Attachment: 0001-Reset-SSTII-in-EchoedRow-constructor.patch
This is indeed compaction related (but not related to secondary indexing at
all). The problem is that compaction may lose some rows.
Because of the way the ReducingIterator works, when we create a new
{Pre|Lazy|Echoed}CompactedRow, we have already decoded the next row key and
the file pointer if after that next row key. Both PreCompactedRow and
LazyCompactedRow handle this correctly by "resetting" their
SSTableIdentityIterator before reading (SSTII.getColumnFamilyWithColumns()
does it for PreCompactedRow and LazilyCompactedRow calls SSTII.reset()
directly). But EchoedRow doesn't handle this correctly. Hence when
EchoedRow.isEmpty() is called, it will call SSTII.hasNext(), that will compare
the current file pointer to the finishedAt value of the iterator. The pointer
being on the next row, this test will always fail and the row will be skipped.
Attaching a patch against 0.8 with a (smaller) unit test.
Note that luckily this doesn't affect 0.7, because it only uses EchoedRow for
cleanup compactions and clean compactions does not use ReducingIterator (and
thus, the underlying SSTII won't have changed when the EchoedRow is built).
I would still be in favor of committing the patch there too, just to make sure
we don't hit this later.
> index scan errors out when zero columns are requested
> -----------------------------------------------------
>
> Key: CASSANDRA-2653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2653
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.8.0 beta 2
> Reporter: Jonathan Ellis
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.7
>
> Attachments: 0001-Reset-SSTII-in-EchoedRow-constructor.patch,
> v1-0001-CASSANDRA-2653-reproduce-regression.txt
>
>
> As reported by Tyler Hobbs as an addendum to CASSANDRA-2401,
> {noformat}
> ERROR 16:13:38,864 Fatal exception in thread Thread[ReadStage:16,5,main]
> java.lang.AssertionError: No data found for
> SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
> finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
> count=0] in DecoratedKey(81509516161424251288255223397843705139,
> 6b657931):QueryPath(columnFamilyName='cf', superColumnName='null',
> columnName='null') (original filter
> SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30],
> finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], reversed=false,
> count=0]) from expression 'cf.626972746864617465 EQ 1'
> at
> org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1517)
> at
> org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:42)
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
