[
https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14032680#comment-14032680
]
Benedict commented on CASSANDRA-7371:
-------------------------------------
Two minor comments:
# In addAllWithSizeDelta, I would only copy the deletionInfo on the first
iteration (if there's a race we'll copy multiple times)
# In RangeTombstoneList.copy we should just allocate an empty array for
starts/ends, as we overwrite the data we copy anyway (this is slightly cheaper,
as the arrays are zeroed before allocation)
Otherwise LGTM
> DELETEs get lost
> ----------------
>
> Key: CASSANDRA-7371
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7371
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: 2.1 git branch since merge commit
> 4722fe70aa9ae1b62772cfa1a1de58ef289445d5 ("RefCount native frames from netty
> to avoid corruption bugs")
> Reporter: Robert Stupp
> Assignee: T Jake Luciani
> Priority: Blocker
> Fix For: 2.1.0
>
> Attachments: 7371.txt, Cassandra7371.java
>
>
> The mentioned commit introduced a bug which is not easy to reproduce:
> Workload description:
> - One INSERT into a table
> - multiple concurrent SELECTs against different tables (one select returns a
> result)
> - One UPDATE against the same table as the INSERT
> - (same) multiple concurrent SELECTs against different tables (one select
> returns a result)
> - One DELETE against the same table as the INSERT
> - (same) multiple concurrent SELECTs against different tables
> Expected is that the last bunch of SELECTs returns no result. But since
> commit SHA the DELETE gets not processed.
> To clarify - the DELETE is not delayed - it is not executed at all.
> Checked against a single node C* "cluster".
> Does only affect unreleased 2.1 - not 2.0 nor 1.2.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
