[ 
https://issues.apache.org/jira/browse/CASSANDRA-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307615#comment-15307615
 ] 

Branimir Lambov commented on CASSANDRA-11882:
---------------------------------------------

Sylvain, the 64k+ keys currently _do not_ work in 3.x. They are not always 
serialized properly. We should find a way to fix the problem and make sure they 
are properly supported, but not as part of this ticket.

While they are not working, it's best to validate and error out early rather 
than accept the writes and let the node fail badly on flush and commit log 
recovery, thus I _would_ include the validation in the 3.x patch.

> 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)

Reply via email to