cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8851) Uncaught exception on thread Thread[SharedPool-Worker-16,5,main] after upgrade to 2.1.3
Date Wed, 18 Mar 2015 23:00:39 GMT


Benedict commented on CASSANDRA-8851:

OK, so the problem does indeed seem to be down to sampling in some way. But not in the way
I expected. It seems that the effective index interval calculation is broken, and firstKeyBeyond
ignores this so works fine. [~thobbs]: couldn't we drop the effective index interval entirely?
We should scan forwards until we hit a record that sorts above us, no? I assume it's there
to cope with equality checks which do not compose the token, but perhaps we should simply
use the minimum effective interval, and after this switch to the slower inequality match path,
since it would not run the risk of this calculation being mistaken (or for now we could just
use the calculation as this mark, without removing it, so that it is only a more accurate

> Uncaught exception on thread Thread[SharedPool-Worker-16,5,main] after upgrade to 2.1.3
> ---------------------------------------------------------------------------------------
>                 Key: CASSANDRA-8851
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: ubuntu 
>            Reporter: Tobias Schlottke
>            Assignee: Benedict
>            Priority: Critical
>             Fix For: 2.1.4
>         Attachments: schema.txt, system.log.gz
> Hi there,
> after upgrading to 2.1.3 we've got the following error every few seconds:
> {code}
> WARN  [SharedPool-Worker-16] 2015-02-23 10:20:36,392
- Uncaught exception on thread Thread[SharedPool-Worker-16,5,main]: {}
> java.lang.AssertionError: null
> 	at ~[apache-cassandra-2.1.3.jar:2.1.3]
> 	at org.apache.cassandra.utils.obs.OffHeapBitSet.capacity( ~[apache-cassandra-2.1.3.jar:2.1.3]
> 	at org.apache.cassandra.utils.BloomFilter.indexes( ~[apache-cassandra-2.1.3.jar:2.1.3]
> 	at org.apache.cassandra.utils.BloomFilter.isPresent( ~[apache-cassandra-2.1.3.jar:2.1.3]
> 	at
> 	at
> 	at org.apache.cassandra.db.columniterator.SSTableSliceIterator.<init>(
> 	at org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(
> 	at org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(
> 	at org.apache.cassandra.db.CollationController.collectAllData(
> 	at org.apache.cassandra.db.CollationController.getTopLevelColumns(
> 	at org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(
> 	at org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(
> 	at org.apache.cassandra.db.Keyspace.getRow( ~[apache-cassandra-2.1.3.jar:2.1.3]
> 	at org.apache.cassandra.db.SliceFromReadCommand.getRow(
> 	at org.apache.cassandra.db.ReadVerbHandler.doVerb( ~[apache-cassandra-2.1.3.jar:2.1.3]
> 	at ~[apache-cassandra-2.1.3.jar:2.1.3]
> 	at java.util.concurrent.Executors$ ~[na:1.7.0_45]
> 	at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$
> 	at [apache-cassandra-2.1.3.jar:2.1.3]
> 	at [na:1.7.0_45]
> {code}
> This seems to crash the compactions and pushes up server load and piles up compactions.
> Any idea / possible workaround?
> Best,
> Tobias

This message was sent by Atlassian JIRA

View raw message