Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C5D4917395 for ; Tue, 28 Apr 2015 18:36:14 +0000 (UTC) Received: (qmail 33695 invoked by uid 500); 28 Apr 2015 18:36:09 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 33658 invoked by uid 500); 28 Apr 2015 18:36:09 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 33647 invoked by uid 99); 28 Apr 2015 18:36:09 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Apr 2015 18:36:09 +0000 Date: Tue, 28 Apr 2015 18:36:09 +0000 (UTC) From: "Jim Witschey (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-9194) Delete-only workloads crash Cassandra MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14517622#comment-14517622 ] Jim Witschey commented on CASSANDRA-9194: ----------------------------------------- [~benedict] Have you decided how to count the size of the data? and is {{MemtableOnHeapSize}} for 2.1 and up/{{MemtableDataSize}} for 2.0 the right JMX metric to use to check correctness? Thanks. > Delete-only workloads crash Cassandra > ------------------------------------- > > Key: CASSANDRA-9194 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9194 > Project: Cassandra > Issue Type: Bug > Environment: 2.0.14 > Reporter: Robert Wille > Assignee: Benedict > Fix For: 2.0.15 > > Attachments: 9194.2.txt, 9194.txt > > > The size of a tombstone is not properly accounted for in the memtable. A memtable which has only tombstones will never get flushed. It will grow until the JVM runs out of memory. The following program easily demonstrates the problem. > {code} > Cluster.Builder builder = Cluster.builder(); > > Cluster c = builder.addContactPoints("cas121.devf3.com").build(); > > Session s = c.connect(); > > s.execute("CREATE KEYSPACE IF NOT EXISTS test WITH replication = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 }"); > s.execute("CREATE TABLE IF NOT EXISTS test.test(id INT PRIMARY KEY)"); > PreparedStatement stmt = s.prepare("DELETE FROM test.test WHERE id = :id"); > int id = 0; > > while (true) > { > s.execute(stmt.bind(id)); > > id++; > }{code} > This program should run forever, but eventually Cassandra runs out of heap and craps out. You needn't wait for Cassandra to crash. If you run "nodetool cfstats test.test" while it is running, you'll see Memtable cell count grow, but Memtable data size will remain 0. > This issue was fixed once before. I received a patch for version 2.0.5 (I believe), which contained the fix, but the fix has apparently been lost, because it is clearly broken, and I don't see the fix in the change logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)