[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[
https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048697#comment-14048697
]
Sylvain Lebresne commented on CASSANDRA-7371:
-
The test added with this ticket broke the {{ant cql-test}} target, most likely
because it extends SchemaLoader. In 2.1 we've added a CQLTester class for CQL
tests that is better than SchemaLoader for a number of reasons. Can we try to
stick to that for CQL tests rather than depending on the java driver?
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
Labels: qa-resolved
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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048838#comment-14048838 ] T Jake Luciani commented on CASSANDRA-7371: --- [~slebresne] This test is specifically testing the netty protocol so makes no sense to remove the netty path. I think all cql tests should be using the netty protocol. Otherwise we aren't really testing the common transport for cql. 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 Labels: qa-resolved 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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14031755#comment-14031755 ] Philip Thompson commented on CASSANDRA-7371: +1 from me. Patch is working on os-x. Tested it out on windows and linux too, the attached unit test passes on each. I found no issues when running dtests with this patch as well. 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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027719#comment-14027719 ] T Jake Luciani commented on CASSANDRA-7371: --- I can reproduce on OSX so that's good, now I can fix. 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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14028127#comment-14028127 ] Robert Stupp commented on CASSANDRA-7371: - patch works from my side: +1 thanks for the quick fix :) off topic: i still do not understand why this only happened on OSX - but it's an argument to stay on Mac for development (flame off) 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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[
https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026203#comment-14026203
]
Robert Stupp commented on CASSANDRA-7371:
-
Regarding the failed tests:
The CQL DELETE gets through - but it is never executed - not just delayed
(verified in cqlsh some seconds later)
I'll check that patch later this evening (CEST - 6/7 hours before EST).
What I did right now is this.
{noformat}
$ uname -a
Darwin macbook-retina.local 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17
23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64
(System is a MacBook Pro/Retina - 16G RAM - Core i7)
$ cd (directory for cassandra source)
$ rm -rf (everything inside the directory)
$ git clone https://github.com/apache/cassandra.git .
$ git checkout -b cassandra-2.1 --track origin/cassandra-2.1
$ cat .git/config
...
[branch cassandra-2.1]
remote = origin
merge = refs/heads/cassandra-2.1
$ pwd
/Users/snazy/devel/cassandra/cassandra/
$ ant publish
$ java -version
java version 1.7.0_55
$ l ~/.ccm/repository
lrwxr-xr-x 1 snazy staff 39 9 Jun 20:21 2.1.0-rc1-snapshot@ -
/Users/snazy/devel/cassandra/cassandra/
$ ccm create -v 2.1.0-rc1-snapshot -n 1 -s --vnodes test
Current cluster is now: test
{noformat}
Run test... (with 1.7.0_55)
31/500 failed
{noformat}
$ ccm remove test
$ git reset -q --hard b29d882df82c1b0aa2c1878c0ba704ac814c69d3
$ rm -rf build
$ ant publish
$ ccm create -v 2.1.0-rc1-snapshot -n 1 -s --vnodes test
Current cluster is now: test
{noformat}
Run test... (with 1.7.0_55)
0/500 failed
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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[
https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027077#comment-14027077
]
Robert Stupp commented on CASSANDRA-7371:
-
It is not reproducible when connecting from Mac to Linux box.
It is not reproducible when connecting from Linux box to Mac.
It is not reproducible when connecting from Linux box to Linux box.
It is not reproducible when connecting from Mac to Linux VM on Mac.
It is not reproducible when connecting from Linux VM on Mac to Mac.
It is not reproducible when connecting from Linux VM on Mac to Linux VM on Mac.
It is only reproducible when both client and server run on OSX.
It does not depend on the Java version (checked with 1.7.0_55, 1.7.0_60,
1.8.0_05, 1.9.0-ea-b16).
Running test from IDE or command line makes no difference.
Can anyone cross check it? I'm a bit frustrated. I see that there is an issue -
but cannot isolate the cause.
{noformat}
Darwin macbook-retina.local 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17
23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64
2.6 GHz Intel Core i7
{noformat}
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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027100#comment-14027100 ] Jonathan Ellis commented on CASSANDRA-7371: --- Crazy! Do you have an OS X box to test on, [~mshuler]? 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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14027106#comment-14027106 ] T Jake Luciani commented on CASSANDRA-7371: --- Yes I'm not able to repro on my linux box I can try osx. I do think I can fix the bug but I really really want to find a way to reproduce it consistently as a unit test 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)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025351#comment-14025351 ] Robert Stupp commented on CASSANDRA-7371: - Do you need a unit test? 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 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 029cd403172f8cc1b96f0828c8e1f8f6d57c0bcc (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. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[
https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025403#comment-14025403
]
Robert Stupp commented on CASSANDRA-7371:
-
oops... lots of these:
{noformat}
WARN [SharedPool-Worker-6] 2014-06-09 19:30:18,893
AbstractTracingAwareExecutorService.java:166 - Uncaught exception on thread
Thread[SharedPool-Worker-6,10,main]: {}
java.lang.AssertionError: null
at
org.apache.cassandra.db.RangeTombstoneList.insertFrom(RangeTombstoneList.java:504)
~[main/:na]
at
org.apache.cassandra.db.RangeTombstoneList.add(RangeTombstoneList.java:147)
~[main/:na]
at
org.apache.cassandra.db.RangeTombstoneList.add(RangeTombstoneList.java:119)
~[main/:na]
at org.apache.cassandra.db.DeletionInfo.add(DeletionInfo.java:231)
~[main/:na]
at
org.apache.cassandra.db.filter.QueryFilter.delete(QueryFilter.java:258)
~[main/:na]
at
org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:206)
~[main/:na]
at
org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:59)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1873)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1681)
~[main/:na]
at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:335)
~[main/:na]
at
org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:59)
~[main/:na]
at
org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1387)
~[main/:na]
at
org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2054)
~[main/:na]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
~[na:1.7.0_55]
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:162)
~[main/:na]
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
[main/:na]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]
{noformat}
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 029cd403172f8cc1b96f0828c8e1f8f6d57c0bcc (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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025429#comment-14025429 ] Robert Stupp commented on CASSANDRA-7371: - It's not only the mentioned commit. I tried with the latest commit (acb4cf62db7e45f9b325fd88a9df4f67efac17b8) and reversed the changes from commit 029cd403172f8cc1b96f0828c8e1f8f6d57c0bcc. The issue persists... strange. 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 029cd403172f8cc1b96f0828c8e1f8f6d57c0bcc (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. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14025519#comment-14025519 ] Robert Stupp commented on CASSANDRA-7371: - I'm really really sorry to blame the wrong commit (shame on me - forgot to remove C*'s build directory). The bug was caused by commit 4722fe70aa9ae1b62772cfa1a1de58ef289445d5 (RefCount native frames from netty to avoid corruption bugs) and *not* [~iamaleksey]'s trivial change. I've verified it with a clean build of b29d882df82c1b0aa2c1878c0ba704ac814c69d3 (works), a clean build of 4722fe70aa9ae1b62772cfa1a1de58ef289445d5 (fails) and a clean build (recent with 4722fe70aa9ae1b62772cfa1a1de58ef289445d5 removed (works). 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 029cd403172f8cc1b96f0828c8e1f8f6d57c0bcc (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. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CASSANDRA-7371) DELETEs get lost
[ https://issues.apache.org/jira/browse/CASSANDRA-7371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026064#comment-14026064 ] T Jake Luciani commented on CASSANDRA-7371: --- [~snazy] I do think there is a bug here but for some reason I'm not able to reproduce with your test on my laptop. I'll submit a patch and see if that fixes it. 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)
