cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "JianwenSun (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-13285) Lower bound [INCL_START_BOUND(event_source) ]is bigger than first returned value
Date Thu, 02 Mar 2017 07:32:45 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15891745#comment-15891745
] 

JianwenSun commented on CASSANDRA-13285:
----------------------------------------

I lookup 3.9 source code and do the remote debug.

assert comparator().compare(lowerBound, ret.clustering()) <= 0
                : String.format("Lower bound [%s ]is bigger than first returned value [%s]
for sstable %s",
                                lowerBound.toString(sstable.metadata),
                                ret.toString(sstable.metadata),
                                sstable.getFilename());

where lowerBound = "event_source" and ret.clustering() = "action" .
so why does the lowerBound = "event_source"?

'lowerBound' was made by getMetadataLowerBound function in which use minClusteringValues and
maxClusteringValues of the sstablemetadata to assignment the value.

"minClusteringValues" is an array with only one item "source_node"
"maxClusteringValues" is an array with only one item "event_source"


notice:  columnfamily(events) only contains 47 rows. some row contains 'source_node' column
while some not.
so i didn't understand why does the 'maxClusteringValues' = "event_source" and 'minClusteringValues'
= 'source_node'.

plz help.


> Lower bound [INCL_START_BOUND(event_source) ]is bigger than first returned value
> --------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13285
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13285
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: JianwenSun
>         Attachments: schema.txt, using cql.png, using thrift.png
>
>
> We do the test of upgrade 1.2.4->3.9 , everything seems ok. but when we query some
data (using thrift) server throw this exception:
> ..  1:07:40 PM
> java.lang.AssertionError: Lower bound [INCL_START_BOUND(event_source) ]is bigger than
first returned value [Row: column1=action | value=] for sstable /opt/cassandra/upgrade/data/OpsCenter/events/mc-10-big-Data.db
> 	at org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:122)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.rows.UnfilteredRowIteratorWithLowerBound.computeNext(UnfilteredRowIteratorWithLowerBound.java:46)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) ~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.utils.MergeIterator$Candidate.advance(MergeIterator.java:374)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.utils.MergeIterator$ManyToOne.advance(MergeIterator.java:186)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.utils.MergeIterator$ManyToOne.computeNext(MergeIterator.java:155)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) ~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:500)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:360)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47) ~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.rows.UnfilteredRowIterator.isEmpty(UnfilteredRowIterator.java:70)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.SinglePartitionReadCommand.withSSTablesIterated(SinglePartitionReadCommand.java:666)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDiskInternal(SinglePartitionReadCommand.java:615)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.SinglePartitionReadCommand.queryMemtableAndDisk(SinglePartitionReadCommand.java:492)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.SinglePartitionReadCommand.queryStorage(SinglePartitionReadCommand.java:358)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:397) ~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1801)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2486)
~[apache-cassandra-3.9.jar:3.9]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_121]
> 	at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:164)
~[apache-cassandra-3.9.jar:3.9]
> 	at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:109) [apache-cassandra-3.9.jar:3.9]
> 	at java.lang.Thread.run(Thread.java:745) [na:1.8.0_121]
> There was no problems when I use cassandra-cli under 1.2.4 cluster and cqlsh under 3.9
clusters to do the query, it occurred only if when I use thrift api to search it. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message