[
https://issues.apache.org/jira/browse/CASSANDRA-11930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-11930:
------------------------------------
Resolution: Fixed
Fix Version/s: (was: 3.0.x)
(was: 3.x)
3.0.7
3.7
Status: Resolved (was: Patch Available)
The new dtest unfortunately failed on that upgrade test run because it was
started before I fixed small bug in the test, but I've run the fixed test many
times locally without any problems. I'm not too familiar with the other
upgrade test failure, but since it has to do with a child process terminating
unexpectedly, I assume it's unrelated to these changes.
So, committed as {{c98b6484e124982b455455c9cd847e0b36d5074b}} to 3.0 and merged
up to 3.7 and trunk. Thanks for the review.
> Range tombstone serialisation between 2.1 and 3.0 nodes (in 3.0 -> 2.1
> direction) is broken for some Thrift deletions
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-11930
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11930
> Project: Cassandra
> Issue Type: Bug
> Components: Coordination
> Reporter: Aleksey Yeschenko
> Assignee: Tyler Hobbs
> Fix For: 3.7, 3.0.7
>
>
> {{LegacyLayout.LegacyRangeTombstoneList::serialize()}} has a broken
> assumption that a range tombstone implies {{CompositeType}}. This is
> incorrect, as you can have non-{{CompositeType}} range tombstones created via
> Thrift in 2.1, and as such wrapping {{clusteringComparator.subtypes()}} in a
> {{CompositeType}} is incorrect. On 2.1/2.2 side, when decoding the range
> tombstone list, {{RangeTombstoneList::deserialize()}} will use the raw type
> to decode start and end bounds, which will end up being confused by the extra
> 2 bytes in the beginning (short length) plus end of component header in the
> end.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
