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 5858310EF0 for ; Mon, 15 Jul 2013 14:16:53 +0000 (UTC) Received: (qmail 60928 invoked by uid 500); 15 Jul 2013 14:16:53 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 60905 invoked by uid 500); 15 Jul 2013 14:16:52 -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 60774 invoked by uid 99); 15 Jul 2013 14:16:51 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Jul 2013 14:16:51 +0000 Date: Mon, 15 Jul 2013 14:16:51 +0000 (UTC) From: "Sylvain Lebresne (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-5762) Lost row marker after TTL expires 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-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13708490#comment-13708490 ] Sylvain Lebresne commented on CASSANDRA-5762: --------------------------------------------- This is a rather annoying problem. To sum it up, if you TTL one column, the row marker is ttled too, because we have no way to know that this is not the last live column in that CQL3 row, but then if there was other non-ttled columns, they will survive the death of the row marker which breaks the invariant that a live row always has a row marker. Tbh, I have a hard time coming with a way to fix this. And so the only workaround that comes to mind would be disallow setting a TTL on an individual columns. That is, you'd have to update all columns of the row to be able to use a TTL, which I hate because 1) it'll look random syntax wise and 2) I'm convinced that being able to TTL individual columns in a row is useful. > Lost row marker after TTL expires > --------------------------------- > > Key: CASSANDRA-5762 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5762 > Project: Cassandra > Issue Type: Bug > Affects Versions: 1.2.6 > Environment: Ubuntu 12.04 > Reporter: Taner Catakli > Assignee: Sylvain Lebresne > Priority: Critical > > I have the following table > cqlsh:loginproject> DESCRIBE TABLE gameservers; > > CREATE TABLE gameservers ( > address inet PRIMARY KEY, > last_update timestamp, > regions blob, > server_status boolean > ) WITH > bloom_filter_fp_chance=0.010000 AND > caching='KEYS_ONLY' AND > comment='' AND > dclocal_read_repair_chance=0.000000 AND > gc_grace_seconds=864000 AND > read_repair_chance=0.100000 AND > replicate_on_write='true' AND > populate_io_cache_on_flush='false' AND > compaction={'class': 'SizeTieredCompactionStrategy'} AND > compression={'sstable_compression': 'SnappyCompressor'}; > after inserting a row and executing the following command: > UPDATE gameservers USING TTL 10 SET server_status = true WHERE address = '192.168.0.100' > after waiting for the ttl to expire, the row will lose its rowmarker making "select address from gameservers" returning 0 results although there are some. > in cassandra-cli the table looks like this: > [default@loginproject] list gameservers; > Using default limit of 100 > Using default cell limit of 100 > ------------------- > RowKey: 192.168.0.100 > => (name=last_update, value=0000000000000017, timestamp=1373884433543000) > => (name=regions, value=, timestamp=1373883701652000) > 1 Row Returned. > Elapsed time: 345 msec(s). > [default@loginproject] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira