3.11 currently not building

[Lerh Chuan Low]

Hi guys,

I saw your message on IRC Jason, Kurt forwarded it to me. Thanks for the
heads up!

3.11 presently doesn't build, I think it may have been due to an accidental
merge gone bad. The original JIRA
https://issues.apache.org/jira/browse/CASSANDRA-13698 has been updated with
a patch and the tests are running (runs locally for me as well), do please
have a look when possible, thanks!

Lerh

Re: TWCS - Disabling Tombstone Compactions for TWCS

[Lerh Chuan Low]

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

Re: TWCS - Disabling Tombstone Compactions for TWCS

[Lerh Chuan Low]

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

Re: Paying off tech debt and correctly naming things

[Lerh Chuan Low]

For reasons others have mentioned (nightmare to continuously update branch
and resolve merge conflicts, existing patches/big features..) it will be a
nightmare. It seems like in software projects (just basing it off personal
experience) people typically refactor if a ticket they are working on
touches the part of the code base that needs refactoring, I've not really
seen a freeze and work off technical debt before (I'll admit upfront I
don't know much).

Thinking about it, the only ones I could come up with are the same as
Sylvain had mentioned, which is start with a small subset and just do only
renaming and cleaning up comments; no logic changes. I would think some
parts of the code may take ages more before a ticket finds its way to it
(and a knowledgable enough person is involved to even guide the refactor).

So definitely, you have my (moral) support if you are going to go with it,
+1 +1 +1

On 22 March 2018 at 00:31, Eric Evans  wrote:

> On Wed, Mar 21, 2018 at 3:48 AM, Sylvain Lebresne 
> wrote:
>
> [ ... ]
>
> > - pure code renaming is one reasonably simple aspect, but quite a few
> > renaming may have user visible impact. Particularly around JMX where many
> > things are name based on their class, and to a lesser extend some of our
> > tools still use "old" naming. We can't and shouldn't ignore those impact:
> > such user visible changes should imo be documented, and we should make
> sure
> > we have a reasonably painless (and thus incremental) upgrade path. My
> hunch
> > is the latter isn't as simple as it seems.
>
> Speaking as someone who has personally been burned by this
> (repeatedly, and it's on-going), please think very carefully before
> making such changes.  I hate to think about of all the hours I wasted
> shaving this breed of yak.
>
> > On Wed, Mar 21, 2018 at 9:06 AM kurt greaves 
> wrote:
>
> [ ... ]
>
> --
> Eric Evans
> john.eric.ev...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Could I trouble someone to run look through JIRA 8460?

[Lerh Chuan Low]

Dear all,

Just wondering if anyone has any available capacity to have a look through
https://issues.apache.org/jira/browse/CASSANDRA-8460 and give their
thoughts on the initial patch I have?

Namely the decisions on having archiving configurable from the YAML but
controlled from the Compaction Strategy and also whether it's headed the
right way as it is at the moment.

Thanks in advance!! (if you do have the time), otherwise please think of me
the next month or whenever you run these thoughts through your head.

:)

Re: Soliciting volunteers for flaky dtests on trunk

[Lerh Chuan Low]

Hey Ariel,

It looks like you've closed the only JIRA I've found on CqlshSmokeTest (
https://issues.apache.org/jira/browse/CASSANDRA-13140) and as you mentioned
in the ticket, it hasn't been failing recently in both CassCI and Apache
Jenkins. I think we're gold for that one.

Would anyone like a hand with anything?

Lerh

On 18 May 2017 at 03:36, Ariel Weisberg <ar...@weisberg.ws> wrote:

> Hi,
>
> Thank you Blake, Lerh Chuan Low, Jason, and Kurt, and anyone else who
> volunteered.
>
> I'm going to look at repair_test.TestRepair which is not quite the same
> as repair_test.incremental_repair test which Blake is looking at.
>
> The one remaining somewhat high pole in the tent is
> cqlsh_tests.CqlshSmokeTest.
>
> Thanks,
> Ariel
>
> On Thu, May 11, 2017, at 01:12 PM, Jason Brown wrote:
> > I've taken
> > CASSANDRA-13507
> > CASSANDRA-13517
> >
> > -Jason
> >
> >
> > On Wed, May 10, 2017 at 9:45 PM, Lerh Chuan Low <l...@instaclustr.com>
> > wrote:
> >
> > > I'll try my hand on https://issues.apache.org/
> jira/browse/CASSANDRA-13182.
> > >
> > > On 11 May 2017 at 05:59, Blake Eggleston <beggles...@apple.com> wrote:
> > >
> > > > I've taken CASSANDRA-13194, CASSANDRA-13506, CASSANDRA-13515,
> > > > and CASSANDRA-13372 to start
> > > >
> > > > On May 10, 2017 at 12:44:47 PM, Ariel Weisberg (ar...@weisberg.ws)
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > The dev list murdered my rich text formatted email. Here it is
> > > > reformatted as plain text.
> > > >
> > > > The unit tests are looking pretty reliable right now. There is a long
> > > > tail of infrequently failing tests but it's not bad and almost all
> > > > builds succeed in the current build environment. In CircleCI it seems
> > > > like unit tests might be a little less reliable, but still usable.
> > > >
> > > > The dtests on the other hand aren't producing clean builds yetl.
> There
> > > > is also a pretty diverse set of failing tests.
> > > >
> > > > I did a bit of triaging of the flakey dtests. I started by cataloging
> > > > everything, but what I found is that the long tail of flakey dtests
> is
> > > > very long indeed so I narrowed focus to just the top frequently
> failing
> > > > tests for now. See https://goo.gl/b96CdO
> > > >
> > > > I created spreadsheet with some of the failing tests. Links to JIRA,
> > > > last time the test was seen failing, and how many failures I found in
> > > > Apache Jenkins across the 3 dtest builds. There are a lot of failures
> > > > not listed. There would be 50+ entries if I cataloged each one.
> > > >
> > > > There are two hard failing tests, but both are already moving along:
> > > > CASSANDRA-13229 (Ready to commit, assigned Alex Petrov, Paulo Motta
> > > > reviewing, last updated April 2017) dtest failure in
> > > > topology_test.TestTopology.size_estimates_multidc_test
> > > > CASSANDRA-13113 (Ready to commit, assigned Alex Petrov, Sam T
> Reviewing,
> > > > last updated March 2017) test failure in
> > > > auth_test.TestAuth.system_auth_ks_is_alterable_test
> > > >
> > > > I think the tests we should tackle first are on this sheet in
> priority
> > > > order https://goo.gl/S3khv1
> > > >
> > > > Suite: bootstrap_test
> > > > Test: TestBootstrap.simultaneous_bootstrap_test
> > > > JIRA: https://issues.apache.org/jira/browse/CASSANDRA-13506
> > > > Last failure: 5/5/2017
> > > > Counted failures: 45
> > > >
> > > > Suite: repair_test
> > > > Test: incremental_repair_test.TestIncRepair.compaction_test
> > > > JIRA: https://issues.apache.org/jira/browse/CASSANDRA-13194
> > > > Last failure: 5/4/2017
> > > > Counted failures: 44
> > > >
> > > > Suite: sstableutil_test
> > > > Test: SSTableUtilTest.compaction_test
> > > > JIRA: https://issues.apache.org/jira/browse/CASSANDRA-13182
> > > > Last failure: 5/4/2017
> > > > Counted failures: 35
> > > >
> > > > Suite: paging_test
> > > > Test: TestPagingWithDeletions.test_ttl_deletions
> > > > JIRA: https://issues.apache.org/jira/browse/CASSANDRA-13507
> > > > Last failure: 4/25/2017
> > > > Counted failures: 31
> > > >
> >