[
https://issues.apache.org/jira/browse/CASSANDRA-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13056385#comment-13056385
]
Sylvain Lebresne commented on CASSANDRA-2653:
---------------------------------------------
bq. doesn't this assert still have the "the query to the index and the data is
not atomic" problem?
No you're right, I focused on adding back the assert forgetting it wasn't safe
in the first place. Attaching v3 based on v2, but instead of asserting that the
row return contains the primary clause column, it skips the row if it doesn't
contain it. That is, instead of asserting the non-corruption of the index, it
ignores any possible corruption. But more importantly (one could hope we don't
have a bug that corrupt indexes), it will avoid returning incoherent result to
the user in the event of a race between reads and writes.
Trying to prevent the race from happening would require synchronization with
write, which will be much harder and less efficient. And we probably need to
have a fix for that out sooner than later (both the error when zero columns are
requested and the possibly to throw assertion errors wrongly).
In the longer term, I think we should explore the possibility of stopping to
care whether our secondary indexes are coherent at all time and repair them at
read time as this may allow us to get rid of the read-before-write. But it's a
longer term goal at best and work for another ticket.
> 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.7.6, 0.8.0 beta 2
> Reporter: Jonathan Ellis
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.7, 0.8.1
>
> Attachments:
> 0001-Handle-data-get-returning-null-in-secondary-indexes.patch,
> 0001-Handle-null-returns-in-data-index-query-v0.7.patch,
> 0001-Reset-SSTII-in-EchoedRow-constructor.patch, 2653_v2.patch,
> 2653_v3.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
