I'm thinking if this row expiry notion doesn't pan out then I might create a 'lastAccessed' column with a secondary index (i think that's right) on it. Then I can periodically run a query to find all lastAccessed columns less than a certain value and manually delete them. Sound reasonable?
-Kal On Tue, Feb 8, 2011 at 12:09 PM, Kallin Nagelberg <kallin.nagelb...@gmail.com> wrote: > Yes I did, on the org.apache.cassandra.db.ColumnFamilies.Main.Session object. > > -Kal > > On Tue, Feb 8, 2011 at 12:00 PM, Sylvain Lebresne <sylv...@datastax.com> > wrote: >> Did you force a major compaction (with jconsole or nodetool) after gc_grace >> has elapsed ? >> On Tue, Feb 8, 2011 at 5:46 PM, Kallin Nagelberg >> <kallin.nagelb...@gmail.com> wrote: >>> >>> Thanks, gc_grace works in the CLI. >>> >>> However, I'm not observing the desired effect. I am setting TTL on a >>> single column in my column family, and I see the columns disappear >>> when using 'list Session' (my columnfamily) in the CLI. I created the >>> column family with gc_grace = 60, and after observing for a few >>> minutes I am still seeing all the rows come back, none of them with >>> columns. I was hoping the GC would delete the empty rows. >>> >>> -Kal >>> >>> On Tue, Feb 8, 2011 at 11:39 AM, Sylvain Lebresne <sylv...@datastax.com> >>> wrote: >>> > Not very logically, It's actually gc_grace, not gc_grace_seconds in the >>> > CLI. >>> > >>> > On Tue, Feb 8, 2011 at 5:34 PM, Kallin Nagelberg >>> > <kallin.nagelb...@gmail.com> wrote: >>> >> >>> >> I'm trying to set the gc_grace_seconds column family parameter but no >>> >> luck.. I got the name of it from the comment in cassandra.yaml: >>> >> >>> >> # - gc_grace_seconds: specifies the time to wait before garbage >>> >> # collecting tombstones (deletion markers). defaults to 864000 >>> >> (10 >>> >> # days). See http://wiki.apache.org/cassandra/DistributedDeletes >>> >> >>> >> create column family Session >>> >> with comparator = UTF8Type >>> >> and keys_cached = 10000 >>> >> and memtable_flush_after = 1440 >>> >> and memtable_throughput = 32 >>> >> and gc_grace_seconds = 60; >>> >> >>> >> error is 'No enum const class >>> >> >>> >> >>> >> org.apache.cassandra.cli.CliUserHelp$ColumnFamilyArgument.GC_GRACE_SECONDS'. >>> >> >>> >> Thanks, >>> >> -Kal >>> >> >>> >> On Tue, Feb 8, 2011 at 11:02 AM, Sylvain Lebresne >>> >> <sylv...@datastax.com> >>> >> wrote: >>> >> >> I hope you don't consider this a hijack of the thread... >>> >> >> >>> >> >> What I'd like to know is the following: >>> >> >> >>> >> >> The GC removes TTL rows some time after they expire, at its >>> >> >> convenience. >>> >> >> But will they stop being returned as soon as they expire? (This is >>> >> >> the >>> >> >> expected behavior...) >>> >> > >>> >> > It is the individual column that have TTL. When a column expires, it >>> >> > becomes >>> >> > a delete tombstone. Now, a row with tombstones (even only them) will >>> >> > show >>> >> > during range request. But the explanation is >>> >> > here: http://wiki.apache.org/cassandra/FAQ#range_ghosts >>> >> > >>> >> >> >>> >> >> On Tue, Feb 8, 2011 at 5:11 PM, Kallin Nagelberg >>> >> >> <kallin.nagelb...@gmail.com> wrote: >>> >> >>> >>> >> >>> So the empty row will be ultimately removed then? Is there a way to >>> >> >>> for the GC to verify this? >>> >> >>> >>> >> >>> Thanks, >>> >> >>> -Kal >>> >> >>> >>> >> >>> On Tue, Feb 8, 2011 at 2:21 AM, Stu Hood <stuh...@gmail.com> wrote: >>> >> >>> > The expired columns were converted into tombstones, which will >>> >> >>> > live >>> >> >>> > for >>> >> >>> > the >>> >> >>> > GC timeout. The "empty" row will be cleaned up when those >>> >> >>> > tombstones >>> >> >>> > are >>> >> >>> > removed. >>> >> >>> > Returning the empty row is unfortunate... we'd love to find a >>> >> >>> > more >>> >> >>> > appropriate solution that might not involve endless scanning. >>> >> >>> > See >>> >> >>> > http://wiki.apache.org/cassandra/FAQ#i_deleted_what_gives >>> >> >>> > http://wiki.apache.org/cassandra/FAQ#range_ghosts >>> >> >>> > >>> >> >>> > On Mon, Feb 7, 2011 at 1:49 PM, Kallin Nagelberg >>> >> >>> > <kallin.nagelb...@gmail.com> wrote: >>> >> >>> >> >>> >> >>> >> I also tried forcing a major compaction on the column family >>> >> >>> >> using >>> >> >>> >> JMX >>> >> >>> >> but the row remains. >>> >> >>> >> >>> >> >>> >> On Mon, Feb 7, 2011 at 4:43 PM, Kallin Nagelberg >>> >> >>> >> <kallin.nagelb...@gmail.com> wrote: >>> >> >>> >> > I tried that but I still see the row coming back on a list >>> >> >>> >> > <columnfamily> in the CLI. My concern is that there will be a >>> >> >>> >> > pointer >>> >> >>> >> > to an empty row for all eternity. >>> >> >>> >> > >>> >> >>> >> > -Kal >>> >> >>> >> > >>> >> >>> >> > On Mon, Feb 7, 2011 at 4:38 PM, Aaron Morton >>> >> >>> >> > <aa...@thelastpickle.com> >>> >> >>> >> > wrote: >>> >> >>> >> >> Deleting all the columns in a row via TTL has the same affect >>> >> >>> >> >> as >>> >> >>> >> >> deleting th >>> >> >>> >> >> row, the data will physically by removed during compaction. >>> >> >>> >> >> >>> >> >>> >> >> Aaron >>> >> >>> >> >> >>> >> >>> >> >> >>> >> >>> >> >> On 08 Feb, 2011,at 10:24 AM, Bill Speirs >>> >> >>> >> >> <bill.spe...@gmail.com> >>> >> >>> >> >> wrote: >>> >> >>> >> >> >>> >> >>> >> >> I don't think this is supported (but I could be completely >>> >> >>> >> >> wrong). >>> >> >>> >> >> However, I'd love to see this functionality as well. >>> >> >>> >> >> >>> >> >>> >> >> How would one go about requesting such a feature? >>> >> >>> >> >> >>> >> >>> >> >> Bill- >>> >> >>> >> >> >>> >> >>> >> >> On Mon, Feb 7, 2011 at 4:15 PM, Kallin Nagelberg >>> >> >>> >> >> <kallin.nagelb...@gmail.com> wrote: >>> >> >>> >> >>> Hey, >>> >> >>> >> >>> >>> >> >>> >> >>> I have read about the new TTL columns in Cassandra 0.7. In >>> >> >>> >> >>> my >>> >> >>> >> >>> case >>> >> >>> >> >>> I'd >>> >> >>> >> >>> like to expire an entire row automatically after a certain >>> >> >>> >> >>> amount >>> >> >>> >> >>> of >>> >> >>> >> >>> time. Is this possible as well? >>> >> >>> >> >>> >>> >> >>> >> >>> Thanks, >>> >> >>> >> >>> -Kal >>> >> >>> >> >>> >>> >> >>> >> >> >>> >> >>> >> > >>> >> >>> > >>> >> >>> > >>> >> >> >>> >> > >>> >> > >>> > >>> > >> >> >
