[jira] [Commented] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875619#comment-15875619
]
Sylvain Lebresne commented on CASSANDRA-13237:
--
bq. The trunk patch doesn't appear to have any changes?
Forgot to commit before pushing, sorry :(. Done now so I'll wait on the CI to
make sure.
> 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)
[jira] [Commented] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15875453#comment-15875453
]
Branimir Lambov commented on CASSANDRA-13237:
-
The trunk patch doesn't appear to have any changes?
Apart from that it looks good to me.
> 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)
[jira] [Commented] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874730#comment-15874730
]
Sylvain Lebresne commented on CASSANDRA-13237:
--
You're right, I didn't re-read the patch and botched it, sorry about that. I've
pushed an update to all branches that fixes both of your point in
{{DataResolver}} (both were indeed typos) and add a new test in
{{DataResolverTest}} to test this.
I did rebased and force pushed the update mostly because I wanted the new test
to be in the first commit so I could easily test it with and without the fixes
(crappy excuse, I know) and I hope this isn't too much trouble (but I truly
only did the changes of your points above).
> 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)
[jira] [Commented] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones
[
https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874391#comment-15874391
]
Branimir Lambov commented on CASSANDRA-13237:
-
The deserializer fix and test look good, but there are some problems in
{{DataResolver}}:
- Shouldn't we be looking at {{openDeletionTime}}
[here|https://github.com/pcmanus/cassandra/commit/ba7d1763c108a4a7d84b91ab9eb9b36d04efb0f5#diff-8781f9483cca1cfc87145c767295cc79R341]?
- Regardless of the result of that test, you are still setting
{{markerToRepair}} on the [next
line|https://github.com/pcmanus/cassandra/commit/ba7d1763c108a4a7d84b91ab9eb9b36d04efb0f5#diff-8781f9483cca1cfc87145c767295cc79R344]
-- I don't think this is the intended behaviour.
- Is it too hard to write a test for the above?
> 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)
