[
https://issues.apache.org/jira/browse/CASSANDRA-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15310074#comment-15310074
]
Branimir Lambov commented on CASSANDRA-11882:
---------------------------------------------
>From [the comments
>above|https://issues.apache.org/jira/browse/CASSANDRA-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306355#comment-15306355]
> 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.
[~Lerh Low], could you create a new issue explaining what goes wrong with 64k+
keys in 3.0+ and assign it to Sylvain?
I restarted the tests as something went wrong with half of them yesterday.
> Clustering Key with ByteBuffer size > 64k throws Assertion Error
> ----------------------------------------------------------------
>
> Key: CASSANDRA-11882
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11882
> 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}
> CONSISTENCY ALL;
> 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
(v6.3.4#6332)
