[
https://issues.apache.org/jira/browse/CASSANDRA-11882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303420#comment-15303420
]
Lerh Chuan Low commented on CASSANDRA-11882:
--------------------------------------------
Hey Branimir and Sylvain, thanks for reviewing. I've updated the patch and
re-ran the tests.
{{overloadBuffer}}: I re-read the Code style documentation, I've made changes
to the braces and moved the comment away so the line isn't overly long, let me
know if there are any more format changes required.
{{assertInvalidThrow}}: Didn't realise this method existed, updated the tests.
{{ByteBufferUtil}}: I've updated it to throw an IllegalArgumentException. I
wasn't certain if it could be reached via another way (I'm not familiar with
the code base, naively I assume no) but I guess the idea was that if it did, at
least the node will not see the other node as down forever after that until
restart. Let me know if you feel strongly to leave it as assert.
I also did try this on C* 3.5, it doesn't suffer from the same problem as 2.1,
which I guess is due to the big revamp of the storage engine :)
> 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
>
> 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)
