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] [Commented] (CASSANDRA-7371) DELETEs get lost
Date Wed, 11 Jun 2014 09:38:02 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027577#comment-14027577
] 

Robert Stupp commented on CASSANDRA-7371:
-----------------------------------------

And it does not depend on the particular netty version (tried with previous version 4.0.17
in C*, and newer 3.9.1 in java driver).
Just two ideas (although I have no clue why that does only happen on OSX) : some strange behaviour
in retain/release in io.netty.ByteBuf ... or some strange behaviour in JDK NIO stuff ([7159361|http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7159361]
+ [7143744|http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7143744] ; both resolved/duplicate)

> 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: 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)

Mime
View raw message