cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones
Date Fri, 17 Feb 2017 14:44:41 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-13237:
-----------------------------------------
    Status: Patch Available  (was: Open)

Attaching patches for the problem below:
| [13237-3.0|https://github.com/pcmanus/cassandra/commits/13237-3.0] | [utests|http://cassci.datastax.com/job/pcmanus-13237-3.0-testall]
| [dtests|http://cassci.datastax.com/job/pcmanus-13237-3.0-dtest] |
| [13237-3.11|https://github.com/pcmanus/cassandra/commits/13237-3.11] | [utests|http://cassci.datastax.com/job/pcmanus-13237-3.11-testall]
| [dtests|http://cassci.datastax.com/job/pcmanus-13237-3.11-dtest] |
| [13237-trunk|https://github.com/pcmanus/cassandra/commits/13237-trunk] | [utests|http://cassci.datastax.com/job/pcmanus-13237-trunk-testall]
| [dtests|http://cassci.datastax.com/job/pcmanus-13237-trunk-dtest] |

The first commit of the 3.0/3.11 patches is actually not doing anything but just adding a
unit test that shows we can indeed create a range tombstone boundary that have the same deletion
on both sides. For that, and because we don't have an easy way to actually write old sstable,
the patch also refactor {{UnfilteredDeserializer.OldFormatDeserializer}} so that it can be
unit tested. So while the diff may look "large-ish", it's really just moving some code around
for the test purposes.

The 2nd commit does 2 things:
# it fixes the legacy deserializer to stop doing this.
# it update the assertion in {{DataResolver}} that breaks with such boundaries (again, same
deletion on both side of the boundary).

Not that while it may sound like the 1st part is enough, we can't guarantee that some use
having already upgraded haven't some bad boundaries already (let's clarify when I say "bad"
that it's really just an small inefficiency so not really a big deal) so we shouldn't break
on those. Still, no point in creating such useless boundaries, hence the 1st part.

The trunk patch really only include the {{DataResolver}} change since legacy code has been
removed there.

> Legacy deserializer can create unexpected boundary range tombstones
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-13237
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13237
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 3.0.x, 3.11.x
>
>
> Most of the code don't generate a range tombstone boundary with the same deletion time
on both side as this is basically useless, and there is some assertion in {{DataResolver}}
that actually expect this. However, the deserializer for legacy sstable doesn't always properly
avoid their creation and we can thus generate them (and break the {{DataResolver}} assertion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message