Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 78666 invoked from network); 28 Dec 2010 10:15:31 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Dec 2010 10:15:31 -0000 Received: (qmail 65731 invoked by uid 500); 28 Dec 2010 10:15:29 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 65635 invoked by uid 500); 28 Dec 2010 10:15:29 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 65626 invoked by uid 99); 28 Dec 2010 10:15:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Dec 2010 10:15:28 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [212.14.72.4] (HELO mail.berlin01.toptarif.de) (212.14.72.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Dec 2010 10:15:20 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) Subject: Re: Adding secondary index: java.lang.ArithmeticException: / by zero From: Timo Nentwig In-Reply-To: <6B6029BD-95B2-492C-ACBC-B4858D689CFE@toptarif.de> Date: Tue, 28 Dec 2010 11:14:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7000ACAD-D241-498B-9311-A77930C129A5@toptarif.de> References: <2EFF65DA-AF14-49EA-8C28-01F6600D8025@toptarif.de> <7264BCF8-4C23-481F-AFF1-ED0B6B71541F@toptarif.de> <6B6029BD-95B2-492C-ACBC-B4858D689CFE@toptarif.de> To: user@cassandra.apache.org X-Mailer: Apple Mail (2.1082) X-Virus-Checked: Checked by ClamAV on apache.org On Dec 27, 2010, at 14:34, Timo Nentwig wrote: > On Dec 24, 2010, at 14:33, Timo Nentwig wrote: >> Any advice what to do with it? >=20 > So, to continue this monologue: I reduced the memtable size for that = CF and the by means of the MBeans figured out that the secondary index = is a CF as well which presumably also holds up to 3 memtables in = memory...that would explain why it runs OOM. Hm. I was wrong. In order to somehow stop cassandra to continue to build = the index I deleted system CF and reimported the schema with modified = memtable flush parameters. But apparently the information to build the = secondary index is stored in the CF's metadata, so shortly after it = starts indexing again and the index shows up in mbeans. However: data is never flushed and grows endlessly because of = (ColumnFamilyStore): if (DatabaseDescriptor.getCFMetaData(metadata.cfId) =3D=3D = null) return null; // column family was dropped. no point in = flushing. Did I hit some problem here or is the data just messed up (was build = with rc1, rc2 and I removed system CF). Sigh... > Anyway, I created an issue (affect rc2 beause there's yet no rc3 to = select in Jira) for the crash at startup: CASSANDRA-1904.