incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <tamas.fold...@thomsonreuters.com>
Subject RE: fromIndex > toIndex in Cassandra 1.2.5
Date Tue, 20 Aug 2013 06:52:34 GMT
All right - we will probably proceed with the upgrade then, thanks for the help!

From: Nate McCall [mailto:nate@thelastpickle.com]
Sent: 19. august 2013 17:31
To: user@cassandra.apache.org
Subject: Re: fromIndex > toIndex in Cassandra 1.2.5

Meant to put this in up top, but if you are upgrading, it would behoove you to upgrade to
the latest 1.2.8 (https://github.com/apache/cassandra/blob/cassandra-1.2/CHANGES.txt)

On Mon, Aug 19, 2013 at 9:57 AM, Nate McCall <nate@thelastpickle.com<mailto:nate@thelastpickle.com>>
wrote:
Quite a bit, IIRC. The thrift methods get_range_slices and get_index_slices where merged under
the hood to share a code path.

On Mon, Aug 19, 2013 at 9:50 AM, <tamas.foldesi@thomsonreuters.com<mailto:tamas.foldesi@thomsonreuters.com>>
wrote:
That's good news.
But the thing is - I don't have the client exception, so I cannot tell if this is what really
happens.
I checked the logs for each of our client applications, but no exceptions, so the only other
possibility is that someone manually runs a bad query. It's possible, but still a bit hard
to believe for me, as we don't have many devs working on this, but we still get the exception
many times a week, an noone claimed ownership... :)

Can you tell if the behaviour here is any different than in Cassandra 1.0? We did not get
any exceptions there at all, so it would give us some confidence to know if filtering did
change to let this through.

From: Nate McCall [mailto:nate@thelastpickle.com<mailto:nate@thelastpickle.com>]
Sent: 19. august 2013 16:23
To: user@cassandra.apache.org<mailto:user@cassandra.apache.org>
Subject: Re: fromIndex > toIndex in Cassandra 1.2.5

This is potentially just a bad query. It looks like ThriftValidation#validateFilterClauses
just checks the indexes and values are of the right type and does not compare actual values.
In other words, the query could have made it that far with a bad comparison value.

What exception are you getting back on the client?

On Mon, Aug 19, 2013 at 8:45 AM, <tamas.foldesi@thomsonreuters.com<mailto:tamas.foldesi@thomsonreuters.com>>
wrote:
Hi,

We are upgrading our 1.0 Cassandra installation to 1.2 (via 1.1), and had Cassandra 1.2.5
running in test for a while.
Everything seems fine except that exceptions like below come sporadically, without correlating
with anything else. They *seem* to come during work hours, so it can be that one of our devs
run invalid commands, but then noone complained about any errors they'd get.
I have not found any user-level exceptions in the client logs either, so I wonder what this
might be, how serious it is, what are the consequences, how to avoid (if necessary), etc...
Unfortunately the logs don't say anything about in which keyspace this occurred - I could
not find any sstables with index 1771 (if that is what that number means...).
Any help is appreciated.

ERROR [ReadStage:1771] 2013-08-13 16:40:17,532 CassandraDaemon.java (line 175) Exception in
thread Thread[ReadStage:1771,5,main]
java.lang.IllegalArgumentException: fromIndex(60) > toIndex(0)
        at java.util.SubList.<init>(AbstractList.java:604)
        at java.util.RandomAccessSubList.<init>(AbstractList.java:758)
        at java.util.AbstractList.subList(AbstractList.java:468)
        at org.apache.cassandra.db.ArrayBackedSortedColumns$SlicesIterator.computeNext(ArrayBackedSortedColumns.java:365)
        at org.apache.cassandra.db.ArrayBackedSortedColumns$SlicesIterator.computeNext(ArrayBackedSortedColumns.java:325)
        at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
        at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
        at org.apache.cassandra.db.Memtable$6.hasNext(Memtable.java:356)
        at org.apache.cassandra.db.filter.QueryFilter$2.getNext(QueryFilter.java:171)
        at org.apache.cassandra.db.filter.QueryFilter$2.hasNext(QueryFilter.java:154)
        at org.apache.cassandra.utils.MergeIterator$OneToOne.computeNext(MergeIterator.java:199)
        at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143)
        at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138)
        at org.apache.cassandra.db.filter.SliceQueryFilter.collectReducedColumns(SliceQueryFilter.java:157)
        at org.apache.cassandra.db.filter.QueryFilter.collateColumns(QueryFilter.java:136)
        at org.apache.cassandra.db.filter.QueryFilter.collateOnDiskAtom(QueryFilter.java:84)
        at org.apache.cassandra.db.ColumnFamilyStore.filterColumnFamily(ColumnFamilyStore.java:1242)
        at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1210)
        at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1126)
        at org.apache.cassandra.db.Table.getRow(Table.java:347)
        at org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:70)
        at org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:44)
        at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:56)
        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)

Thanks,
Tamas

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Tamas Foldesi
Senior Software Engineer
Thomson Reuters





Mime
View raw message