incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dane Miller <d...@optimalsocial.com>
Subject Re: IndexOutOfBoundsException during repair, streaming
Date Tue, 02 Apr 2013 20:41:02 GMT
On Mon, Apr 1, 2013 at 10:19 PM, aaron morton <aaron@thelastpickle.com> wrote:
> ERROR [Thread-232] 2013-04-01 22:22:21,760 CassandraDaemon.java (line
> 133) Exception in thread Thread[Thread-232,5,main]
> java.lang.IndexOutOfBoundsException: index (2) must be less than size (2)
>        at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:305)
>        at
> com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:284)
>        at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:81)
>        at
> org.apache.cassandra.db.marshal.CompositeType.getComparator(CompositeType.java:96)
>
> Something odd in the schema world perhaps.
>
> Has the schema changed recently?

No, not recently.  But during development we experimented with other
comparator types for those CFs.  More info below.

> Do yo have more than one schema in the cluster ? (describe cluster in
> cassandra-cli)

I don't think so, that command in cassandra-cli shows just a single
schema in the cluster:

Cluster Information:
   Snitch: org.apache.cassandra.locator.Ec2Snitch
   Partitioner: org.apache.cassandra.dht.RandomPartitioner
   Schema versions:
126b31ad-3660-3831-9d4f-c6763c9acc97: [ ...ip list... ]


This error happened on a CF where the composite is: (Integer, UTF8)

I'm a bit stumped about how we could get the an index==2 in that code
pathway.  See here:
https://github.com/apache/cassandra/blob/cassandra-1.2.1/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java

...start at line 63 in compare.

My Java is terrible, but all of our CompositeTypes are composites of
only two types.  Thus the counter 'i' should never get up to 2 (it is
used to access by index to individual comparator types within the
composite), unless the value of the first two components in each of
the column names being compared are equal, which should be impossible.

During development we experimented with other comparator types for
those CFs.  We deleted and recreated those CFs before moving into
production mode.  Is there a chance Cassandra 'remembers' these old
types from a deleted CF that shares a name with an existing CF?  Could
that be causing improper parsing of comparator column names?

That we enter this code pathway from a section that seems to want to
clean up tombstones makes me think this is a possibility, that there
is a tombstone somewhere whose composite column name is causing
issues.

Dane

Mime
View raw message