osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TWCS - Disabling Tombstone Compactions for TWCS


Hi Eric,

Np, I was curious as to why it did that as well. As it turns out, there's
actually a JIRA where it has taken another person by surprise:
https://issues.apache.org/jira/browse/CASSANDRA-14496. You could maybe bump
it too :)

On 7 June 2018 at 03:39, Eric Stevens <mightye@xxxxxxxxx> wrote:

> That's helpful background, thanks Lerh!  It does seem intentional.
>
> I'd suggest that this violates principal of least surprise (unset defaults
> should have the same effect as setting same to default values), and should
> be worth calling out as a separate option for both DTCS and TWCS.
>
> On Mon, Jun 4, 2018 at 6:02 PM Lerh Chuan Low <lerh@xxxxxxxxxxxxxxx>
> wrote:
>
> > Hi Eric,
> >
> > I think it has something to do with the same reason it is disabled in
> DTCS:
> > https://issues.apache.org/jira/browse/CASSANDRA-9234 can shed more
> light.
> >
> >
> >
> > On 5 June 2018 at 09:02, Eric Stevens <mightye@xxxxxxxxx> wrote:
> >
> > > I'm trying to understand the reasoning behind this stanza in Time
> > Windowed
> > > Compaction Strategy's init:
> > > https://github.com/apache/cassandra/blob/cassandra-3.0.
> > > 15/src/java/org/apache/cassandra/db/compaction/
> > > TimeWindowCompactionStrategy.java#L63-L69
> > >
> > > Reposted (and slightly reformatted) here for convenience:
> > > if (
> > >
> > > !options.containsKey(AbstractCompactionStrategy.
> > > TOMBSTONE_COMPACTION_INTERVAL_OPTION)
> > > &&
> > >
> > > !options.containsKey(AbstractCompactionStrategy.
> > > TOMBSTONE_THRESHOLD_OPTION)
> > > )
> > > {
> > >     disableTombstoneCompactions = true;
> > >     logger.debug("Disabling tombstone compactions for TWCS");
> > > }
> > > else
> > >     logger.debug("Enabling tombstone compactions for TWCS");
> > >
> > > If you have left both tombstone compaction interval, and tombstone
> > > threshold at default values, you are *opting out* of tombstone
> > compactions?
> > >
> > > This was certainly a surprising side effect to us, as we expected unset
> > > values to have the same exact effect as setting those values to their
> > > defaults.
> > >
> > > I'm wondering if someone can shed some more light on this, or if this
> > > should be considered a bug (it seems really intentional).
> > >
> >
>