Return-Path: Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: (qmail 31482 invoked from network); 21 Jul 2010 18:56:17 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Jul 2010 18:56:17 -0000 Received: (qmail 81963 invoked by uid 500); 21 Jul 2010 18:56:17 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 81933 invoked by uid 500); 21 Jul 2010 18:56:16 -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 81923 invoked by uid 99); 21 Jul 2010 18:56:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 18:56:16 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 18:56:13 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o6LItqa1017282 for ; Wed, 21 Jul 2010 18:55:52 GMT Message-ID: <3294933.501431279738552075.JavaMail.jira@thor> Date: Wed, 21 Jul 2010 14:55:52 -0400 (EDT) From: "Jon Hermes (JIRA)" To: commits@cassandra.apache.org Subject: [jira] Issue Comment Edited: (CASSANDRA-1276) GCGraceSeconds per ColumnFamily In-Reply-To: <3855868.355931279048851665.JavaMail.jira@thor> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/CASSANDRA-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890819#action_12890819 ] Jon Hermes edited comment on CASSANDRA-1276 at 7/21/10 2:54 PM: ---------------------------------------------------------------- Fixed conflicts from some other commit. Not seeing any consistent test failures (and the inconsistent tests are not the two named above (and they're not related as I'm seeing them be inconsistent on a clean checkout)). was (Author: jhermes): Fixed conflicts from some other commit. Not seeing any consistent test failures (and the inconsistent tests are not the two named above). > GCGraceSeconds per ColumnFamily > ------------------------------- > > Key: CASSANDRA-1276 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1276 > Project: Cassandra > Issue Type: Improvement > Components: Core > Affects Versions: 0.7 > Reporter: B. Todd Burruss > Assignee: Jon Hermes > Priority: Minor > Fix For: 0.7 > > Attachments: 1276-v4.txt, 1276-v5.txt > > > From: Jonathan Ellis [jbellis@gmail.com] > Received: 7/12/10 9:15 PM > To: user@cassandra.apache.org [user@cassandra.apache.org] > Subject: Re: GCGraceSeconds per ColumnFamily/Keyspace > Probably. Can you open a ticket? > On Mon, Jul 12, 2010 at 10:41 PM, Todd Burruss wrote: > > Is it possible to get this feature in 0.7? > > > > > > > > -----Original Message----- > > From: Jonathan Ellis [jbellis@gmail.com] > > Received: 7/12/10 5:06 PM > > To: user@cassandra.apache.org [user@cassandra.apache.org] > > Subject: Re: GCGraceSeconds per ColumnFamily/Keyspace > > > > GCGS per CF sounds totally reasonable to me. > > > > On Mon, Jul 12, 2010 at 6:33 PM, Todd Burruss wrote: > >> I have two CFs in my keyspace. one i care about allowing a good amount of > >> time for tombstones to propagate (GCGraceSeconds large) ... but the other i > >> couldn't care and in fact i want them gone ASAP so i don't iterate over > >> them. has any thought been given to making this setting per Keyspace or per > >> ColumnFamily? > >> > >> my scenario is that i add columns to rows in one CF, UserData, with > >> logging data or activity, but we only want to keep, say 5000 columns per > >> user. So i also store the user's ID in another CF, PruneCollection, and > >> periodically iterate over it using the IDs found in PruneCollection to > >> "prune" the columns in UserData - and then immediately delete the ID from > >> PruneCollection. if the code is adding, say 50 IDs per second to > >> PruneCollection then the number of deleted keys starts to build up, forcing > >> my iterator to skip over large amounts of deleted keys. With a small > >> GCGraceSeconds these keys are removed nicely, but i can't do that because it > >> affects the tombstones in UserData as well, which need to be propagated. > >> > >> thoughts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.