cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-7371) DELETEs get lost
Date Mon, 09 Jun 2014 18:45:08 GMT

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

Robert Stupp updated CASSANDRA-7371:
------------------------------------

    Description: 
The mentioned commit (merged to 2.1 from 1.2 via 2.0) 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".

The above works with 2.0.8 and against 2.1.0-* - but not C* code since git commit 4722fe70aa9ae1b62772cfa1a1de58ef289445d5
("RefCount native frames from netty to avoid corruption bugs") from June, 5th.

I am not sure whether this bug also occurs in 1.2 or 2.0 branches (didn't check that).

It is not always reproducible - approx 1 of 50 tries run into this issue.

If you have difficulties in finding the reason, I can provide a unit test for that.

  was:
The mentioned commit (merged to 2.1 from 1.2 via 2.0) 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".

The above works with 2.0.8 and against 2.1.0-* - but not C* code since git commit 4722fe70aa9ae1b62772cfa1a1de58ef289445d5
("Fix rare potential NPE in HHOM page size calculation") from June, 5th.

I am not sure whether this bug also occurs in 1.2 or 2.0 branches (didn't check that).

It is not always reproducible - approx 1 of 50 tries run into this issue.

If you have difficulties in finding the reason, I can provide a unit test for that.


> 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 029cd403172f8cc1b96f0828c8e1f8f6d57c0bcc
("Fix rare potential NPE in HHOM page size calculation")
>            Reporter: Robert Stupp
>            Assignee: Aleksey Yeschenko
>            Priority: Blocker
>             Fix For: 2.1.0
>
>         Attachments: Cassandra7371.java
>
>
> The mentioned commit (merged to 2.1 from 1.2 via 2.0) 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".
> The above works with 2.0.8 and against 2.1.0-* - but not C* code since git commit 4722fe70aa9ae1b62772cfa1a1de58ef289445d5
("RefCount native frames from netty to avoid corruption bugs") from June, 5th.
> I am not sure whether this bug also occurs in 1.2 or 2.0 branches (didn't check that).
> It is not always reproducible - approx 1 of 50 tries run into this issue.
> If you have difficulties in finding the reason, I can provide a unit test for that.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message