[
https://issues.apache.org/jira/browse/CASSANDRA-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037514#comment-15037514
]
Sylvain Lebresne commented on CASSANDRA-10374:
----------------------------------------------
It occurred to me that we might not want to commit this to 2.1/2.2. The problem
is that those versions still support the protocol v1 and v2, so while you can
insert values greater than 64k in collections, another client that is using
v1/v2 wouldn't be able to read it correctly. I suppose we could say that if you
start using this you should be sticking to the protocol v3, but it's still feel
a bit easy to shoot yourself in the foot. And 3.0 removes pre-v3 protocol
versions, so this feels like the ideal version to lift that limitation (in
theory you can still have a mixed-version cluster with pre-3.0 nodes that talk
to clients using the v2 protocol, but that is starting to be far fetched since
you'd kind of need to upgrade your client to v3 first if you want to start a
3.0 upgrade).
Anyway, I'm +1 on the 3.0 patch but I haven't looked closely to the other
versions. And I suggest we commit to 3.0 only unless someone has a strong
objection (knowing that if someone is motivated enough to have this in previous
versions, he can apply the attached patches manually).
> List and Map values incorrectly limited to 64k size
> ---------------------------------------------------
>
> Key: CASSANDRA-10374
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10374
> Project: Cassandra
> Issue Type: Bug
> Reporter: Tyler Hobbs
> Assignee: Benjamin Lerer
> Priority: Minor
> Fix For: 3.0.1, 3.1, 2.1.x, 2.2.x
>
>
> With the v3 native protocol, we switched from encoding collection element
> sizes with shorts to ints. However, in {{Lists.java}} and {{Maps.java}}, we
> still validate that list and map values are smaller than
> {{MAX_UNSIGNED_SHORT}}.
> Map keys and set elements are stored in the cell name, so they're implicitly
> limited to the cell name size limit of 64k. However, for non-frozen
> collections, this limitation should not apply, so we probably don't want to
> perform this check here for those either.
> The fix should include tests where we exceed the 64k limit for frozen and
> non-frozen collections. In the case of non-frozen lists and maps, we should
> verify that the 64k cell-name size limit is enforced in a friendly way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
