cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-11882) Clustering Key with ByteBuffer size > 64k throws Assertion Error
Date Wed, 01 Jun 2016 10:41:59 GMT


Sylvain Lebresne commented on CASSANDRA-11882:

bq. From the comments above I understand the fix will need a change in StatsMetadata format,
which could require major version change or would otherwise be involved enough to warrant
a separate ticket.

Hum, somehow missed that comment, sorry. I guess that make sense, but this only limit each
clustering column value to be <= 64k, while the patch currently limit the total size of
all clustering values to be <= 64k. I guess if we don't forget to create a ticket to fix
the sstable metadata (which you can indeed feel free to assign to me), then I guess I'm fine
refusing larger than 64k values for clustering columns for now, as long as we don't limit
the {{Clustering}} as a whole.

> Clustering Key with ByteBuffer size > 64k throws Assertion Error
> ----------------------------------------------------------------
>                 Key: CASSANDRA-11882
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: CQL, Streaming and Messaging
>            Reporter: Lerh Chuan Low
>             Fix For: 2.1.x, 2.2.x
>         Attachments: 11882-2.1.txt, 11882-2.2.txt, 11882-3.X.txt
> Setup:
> {code}
> CREATE KEYSPACE Blues WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor'
: 2};
> CREATE TABLE test (a text, b text, PRIMARY KEY ((a), b))
> {code}
> There currently doesn't seem to be an existing check for selecting clustering keys that
are larger than 64k. So if we proceed to do the following select:
> {code}
> SELECT * FROM Blues.test WHERE a = 'foo' AND b = 'something larger than 64k';
> {code}
> An AssertionError is thrown in `ByteBufferUtil` with just a number and an error message
detailing 'Coordinator node timed out waiting for replica nodes responses' . Additionally,
because an error extends Throwable (it's not a subclass of Exception), it's not caught so
the connection between the coordinator node and the other nodes which have the replicas seem
to be 'stuck' until it's restarted. Any other subsequent queries, even if it's just SELECT
where a = 'foo' and b = 'bar', will always return the Coordinator timing out waiting for replica
nodes responses'.

This message was sent by Atlassian JIRA

View raw message