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
> >>> >> >>>
> >>> >> >>
> >>> >> >
> >>> >
> >>> >
> >>
> >
> >
>

Reply via email to