[jira] [Commented] (CASSANDRA-11882) Clustering Key with ByteBuffer size > 64k throws Assertion Error

["Lerh Chuan Low (JIRA)" <ji...@apache.org>]

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

Lerh Chuan Low commented on CASSANDRA-11882:
--------------------------------------------

I can't find any ways of assigning it to myself, is it a permissions issue?

I've basically made a really simple patch - it just throws an IOException instead of an AssertionError (but it looks like there are many asserts scattered around the code base, any reason why?) with a more helpful message so that the coordinator doesn't see the other nodes as down forever. I've also written a couple of tests and attempted to use the existing logic in QueryProcessor (That looks like the right place to put it) to sanitize the SELECT to begin with. Feel free to leave behind any comments! 

> 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
>            Priority: Minor
>             Fix For: 2.1.x
>
>         Attachments: 11882-2.1.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)