Re: Cassandra on RocksDB experiment result

2017-04-19 Thread Jon Haddad
I have no clue what it would take to accomplish a pluggable storage engine, but I love this idea. Obviously the devil is in the details, & a simple K/V is very different from supporting partitions, collections, etc, but this is very cool & seems crazy not to explore further. Will you be

Re: CASSANDRA-9472 Reintroduce off heap memtables - patch to 3.0

2017-07-31 Thread Jon Haddad
+1. IMO there’s very little reason to use 3.0 at this point. If someone wants to back port and make a 3.0 patch publicly available, cool, but merging it into 3.0 after 2 years doesn’t make much sense to me. > On Jul 31, 2017, at 9:26 AM, Jeremiah D Jordan > wrote:

Re: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Jon Haddad
focusedCommentId=16188758=com.atlassian.jira. >> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758 >> >> Thanks, >> Thomas >> >> -Original Message- >> From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon >> Haddad >> S

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Jon Haddad
error message when MV is >> disabled and someone tries to use it, something like: >> >> "MV has been disabled, to enable it, turn on the flag in >> cassandra.yaml" so users don't spend 3h searching around >> >> >> On Mon, Oct 2, 2017

Re: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Jon Haddad
You’re saying the same memory leak happens under 3.11? > On Oct 2, 2017, at 1:04 PM, Aleksey Yeshchenko wrote: > > Thomas, > > I would maybe agree with waiting for a while because of it, if we had a > proper fix at least under review - or in progress by someone. > > But

Re: Weekly Cassandra Wrap-Up: Oct 16 Edition

2017-10-16 Thread Jon Haddad
Regarding the stress tests, if you’re willing to share, I’m starting a repo where we can keep a bunch of different stress profiles. I’d like to start running them on releases before we agree to push them out. If anyone has a stress test they are willing to share, please get in touch with me!

Re: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Jon Haddad
The comment at the end of CASSANDRA-13754 is a bit concerning, as it was from yesterday and the user is seeing heap issues. It would be unfortunate to have to pull the release if it’s suffering from a major memory leak. > On Oct 2,

Re: [VOTE] Release Apache Cassandra 3.0.15

2017-10-02 Thread Jon Haddad
+1 > On Oct 2, 2017, at 11:00 AM, Brandon Williams wrote: > > +1 > > On Oct 2, 2017 12:58 PM, "Aleksey Yeshchenko" wrote: > >> +1 >> >> — >> AY >> >> On 2 October 2017 at 18:18:26, Michael Shuler (mich...@pbandjelly.org) >> wrote: >> >> I propose the

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Jon Haddad
Having now helped a few folks that have put MVs into prod without realizing what they got themselves into, I’m +1 on a flag disabling the feature by default. A WARN message would not have helped them. > On Oct 2, 2017, at 10:56 AM, Blake Eggleston wrote: > > Yeah I’m

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Jon Haddad
There’s a big difference between removal of a protocol that every single C* user had to use and disabling a feature which is objectively broken and almost nobody is using. Nobody is talking about removing MVs. If you want to use them you can enable them very trivially, but it should be an

Re: Proposal to retroactively mark materialized views experimental

2017-09-29 Thread Jon Haddad
I’m very much +1 on this, and to new features in general. I think having a clear line in which we classify something as production ready would be nice. It would be great if committers were using the feature in prod and could vouch for it’s stability. > On Sep 29, 2017, at 1:09 PM, Blake

Re: Proposal to retroactively mark materialized views experimental

2017-10-04 Thread Jon Haddad
l.com> wrote: > > On Wed, Oct 4, 2017 at 12:09 PM, Jon Haddad <j...@jonhaddad.com > <mailto:j...@jonhaddad.com>> wrote: > >> MVs work fine for *some use cases*, not the general use case. That’s why >> there should be a flag. To opt into the feature whe

Re: Proposal to retroactively mark materialized views experimental

2017-10-04 Thread Jon Haddad
So you’d rather continue to lie to users about the stability of the feature rather than admitting it was merged in prematurely? I’d rather come clean and avoid future problems, and give people the opportunity to stop using MVs rather than let them keep taking risks they’re unaware of. This is

Re: Proposal to retroactively mark materialized views experimental

2017-10-04 Thread Jon Haddad
the other punching bags that have come up in this thread) > > You're right, Jon. That's clearly exactly what I'm saying. > > > On Wed, Oct 4, 2017 at 2:39 PM, Jon Haddad <j...@jonhaddad.com> wrote: > >> So you’d rather continue to lie to users about the stability o

Re: [PROPOSAL] Migrate to pytest from nosetests for dtests

2017-11-28 Thread Jon Haddad
+1 I stopped using nose a long time ago in favor of py.test. It’s a significant improvement. > On Nov 28, 2017, at 10:49 AM, Michael Kjellman wrote: > > I'd like to propose we move from nosetest to pytest for the dtests. It looks > like nosetests is basically abandoned,

duration based config settings

2017-12-04 Thread Jon Haddad
I ways back I had entire CASSANDRA-13976 out of sheer annoyance to change the hint time to be in minutes instead of ms. Millisecond based resolution is a bit absurd for things like hints. I figured minutes would be better, but after some back and forth realized durations (3h, 30m, etc) would

Re: duration based config settings

2017-12-04 Thread Jon Haddad
Sure, I’m fine w/ letting the _ms settings work indefinitely. Can revisit retiring them if there’s ever a real need, am OK if that never happens. I’ll create the JIRA. > On Dec 4, 2017, at 5:19 PM, Nate McCall wrote: > >> I'd be in favour of never retiring the _ms format

Re: custom validation before replication

2017-11-16 Thread Jon Haddad
Looks like you’ve got this thread going on the user & dev ML. This list is the dev one, and is meant for discussion of the Cassandra project. Would everyone mind replying to the thread of the same name on the user list instead? > On Nov 16, 2017, at 1:36 PM, Abdelkrim Fitouri

Re: Apache Cassandra Wiki access

2017-12-07 Thread Jon Haddad
The wiki is effectively dead. Please contribute to the in tree docs section: https://github.com/apache/cassandra/tree/trunk/doc I recently merged in an improvement that uses Docker to generate the docs. The short version: cd ./doc #

Re: CASSANDRA-8527

2018-01-05 Thread Jon Haddad
tune around that already. I don't think >> we need another yaml setting to enable/disable counting deleted rows for >> these thresholds, especially because it's going into 4.0. It *might* be a >> good idea to bump the tombstone failure threshold default as a safety net >> t

Re: CASSANDRA-8527

2017-12-21 Thread Jon Haddad
il.com> wrote: > > +1 to report range tombstones. This one is quite tricky indeed to track > > +1 to Mockito too, with the reserve that it should be used wisely > > On Thu, Dec 21, 2017 at 9:11 PM, Jon Haddad <j...@jonhaddad.com> wrote: > >> I had suggested to A

Re: [VOTE] Release Apache Cassandra 2.1.20

2018-02-12 Thread Jon Haddad
+1 > On Feb 12, 2018, at 12:30 PM, Michael Shuler wrote: > > I propose the following artifacts for release as 2.1.20. > > sha1: b2949439ec62077128103540e42570238520f4ee > Git: >

Re: [VOTE] Release Apache Cassandra 3.11.2

2018-02-12 Thread Jon Haddad
I’m a +1 on getting this into 3.11.2. > On Feb 12, 2018, at 1:11 PM, mck wrote: > >> I propose the following artifacts for release as 3.11.2. >> … >> The vote will be open for 72 hours (longer if needed). > > > I just pushed the back-port of CASSANDRA-13080 (under

Re: [VOTE] Release Apache Cassandra 2.2.12

2018-02-13 Thread Jon Haddad
+1 > On Feb 13, 2018, at 7:21 AM, Marcus Eriksson wrote: > > +1 > > On Tue, Feb 13, 2018 at 4:18 PM, Gary Dusbabek wrote: > >> +1 >> >> On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler >> wrote: >> >>> I propose the following

Re: [VOTE] Release Apache Cassandra 3.0.16

2018-02-13 Thread Jon Haddad
+1 > On Feb 13, 2018, at 10:52 AM, Josh McKenzie wrote: > > +1 > > On Feb 13, 2018 9:20 AM, "Marcus Eriksson" wrote: > >> +1 >> >> On Tue, Feb 13, 2018 at 1:29 PM, Aleksey Yeshchenko >> wrote: >> >>> +1 >>> >>> — >>> AY >>> >>>

Re: [VOTE] (Take 3) Release Apache Cassandra 3.11.2

2018-02-14 Thread Jon Haddad
+1 > On Feb 14, 2018, at 1:21 PM, Brandon Williams wrote: > > +1 > > On Wed, Feb 14, 2018 at 3:09 PM, Michael Shuler > wrote: > >> I propose the following artifacts for release as 3.11.2. >> >> sha1: 1d506f9d09c880ff2b2693e3e27fa58c02ecf398 >> Git:

Re: Why isn't there a separate JVM per table?

2018-02-22 Thread Jon Haddad
Yeah, I’m in the compaction on it’s own JVM camp, in an ideal world where we’re isolating crazy GC churning parts of the DB. It would mean reworking how tasks are created and removal of all shared state in favor of messaging + a smarter manager, which imo would be a good idea regardless. It

Re: Cassandra Needs to Grow Up by Version Five!

2018-02-21 Thread Jon Haddad
Ken, Maybe it’s not clear how open source projects work, so let me try to explain. There’s a bunch of us who either get paid by someone or volunteer on our free time. The folks that get paid, (yay!) usually take direction on what the priorities are, and work on projects that directly affect

Re: CASSANDRA-8527

2017-12-21 Thread Jon Haddad
I had suggested to Alex we kick this discussion over to the ML because the change will have a significant impact on the behavior of Cassandra when doing reads with range tombstones that cover a lot of rows. The behavior now is a little weird, a single tombstone could shadow hundreds of

Re: A JIRA proposing a seperate repository for the online documentation

2018-03-15 Thread Jon Haddad
Murukesh is correct on a very useable, pretty standard process of multi-versioned docs. I’ll put my thoughts in a JIRA epic tonight. I’ll be a multi-phase process. Also correct in that I’d like us to move to Hugo for the site, I’d like us to have a unified system between the site & the docs,

Re: Roadmap for 4.0

2018-04-04 Thread Jon Haddad
+1, well said Scott. > On Apr 4, 2018, at 5:13 PM, Jonathan Ellis wrote: > > On Wed, Apr 4, 2018, 7:06 PM Nate McCall wrote: > >> Top-posting as I think this summary is on point - thanks, Scott! (And >> great to have you back, btw). >> >> It feels to me

Re: Roadmap for 4.0

2018-04-04 Thread Jon Haddad
Agreed with Josh. There’s nothing set in stone after we release 4.0, trying to extrapolate what we do here for the rest of humanity’s timeline isn’t going to be a useful exercise. Regarding building a big list - it’s of no value. In fact, if we’re already talking about releasing 4.0 we

Re: Repair scheduling tools

2018-04-04 Thread Jon Haddad
Implementation details aside, I’m firmly in the “it would be nice of C* could take care of it” camp. Reaper is pretty damn easy to use and people *still* don’t put it in prod. > On Apr 4, 2018, at 4:16 AM, Rahul Singh wrote: > > I understand the merits of

Re: Roadmap for 4.0

2018-04-12 Thread Jon Haddad
Sept works for me too. I’ll be involved in the validation process before the cutoff date. > On Apr 12, 2018, at 3:17 PM, Carlos Rolo wrote: > > I will commit time to test (not a full validation, but at least go through > operations) regardless of the date. Both seems fine

Re: Roadmap for 4.0

2018-04-03 Thread Jon Haddad
I’d prefer to time box it as well. I like Sylvain’s suggestion, although I’d also be comfortable with setting a more aggressive cutoff date for features (maybe a month), given all the stuff that’s already in. If we plan on a follow up (4.1/5.0) in 6 months I *hope* there will be less of a

Re: Paying off tech debt and correctly naming things

2018-03-22 Thread Jon Haddad
s >>> in flight, things that actually pay off some technical debt, and dealing >> with such renames is rebase hell :\ >>> >>> That said, there is good time for such renames - it’s during those major >> refactors and rewrites. When you are >>> chang

Paying off tech debt and correctly naming things

2018-03-20 Thread Jon Haddad
Whenever I hop around in the codebase, one thing that always manages to slow me down is needing to understand the context of the variable names that I’m looking at. We’ve now removed thrift the transport, but the variables, classes and comments still remain. Personally, I’d like to go in and

Re: Audit logging to tables.

2019-04-03 Thread Jon Haddad
; compaction > > >> > > > >> > > pressure, > > >> > > > >> > > > > > >>> flushing > > >> > > > >> > > > > > >>>>> pressure, etc) from that, there's a > > compo

Re: Stabilising Internode Messaging in 4.0

2019-04-04 Thread Jon Haddad
Given the number of issues that are addressed, I definitely think it's worth strongly considering merging this in. I think it might be a little unrealistic to cut the first alpha after the merge though. Being realistic, any 20K+ LOC change is going to introduce its own bugs, and we should be

TLP tools for stress testing and building test clusters in AWS

2019-04-12 Thread Jon Haddad
I don't want to derail the discussion about Stabilizing Internode Messaging, so I'm starting this as a separate thread. There was a comment that Josh made [1] about doing performance testing with real clusters as well as a lot of microbenchmarks, and I'm 100% in support of this. We've been

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-15 Thread Jon Haddad
t; > I am from Australia so 5pm London time is ours 2am next day so your > > > Wednesday morning is my Thursday night. Wednesday early morning so > > > your Tuesday morning and London's afternoon would be the best. > > > > > > Recording the thing would be defini

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-16 Thread Jon Haddad
Yes, sorry about that. Wednesday morning 9am PT On Tue, Apr 16, 2019 at 3:26 AM Benedict Elliott Smith wrote: > Just to confirm, this is on Wednesday? > > > On 15 Apr 2019, at 22:38, Jon Haddad wrote: > > > > Hey all, > > > > I've set up a Zoom call for 9

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-16 Thread Jon Haddad
osovic < > >>> stefan.mikloso...@instaclustr.com> wrote: > >>> > >>>> Hi Jon, > >>>> > >>>> I would like be on that call too but I am off on Thursday. > >>>> > >>>> I am from Australia so 5pm London time is ours 2am

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-12 Thread Jon Haddad
; > > > Hey Jon, > > > > This sounds exciting and pretty useful, thanks. > > > > Looking forward to using tlp-stress for validating 15066 performance. > > > > We should touch base some time next week to pick a comprehensive set of > > workloads an

Re: [VOTE] remove the old wiki

2019-06-04 Thread Jon Haddad
of establishing a framework > in which to think about something. Maybe. > > On Tue, Jun 4, 2019 at 2:47 PM Jon Haddad wrote: > > > I assume everyone here knows the old wiki hasn't been maintained, and is > > years out of date. I propose we sunset it completely and delete

[VOTE] remove the old wiki

2019-06-04 Thread Jon Haddad
I assume everyone here knows the old wiki hasn't been maintained, and is years out of date. I propose we sunset it completely and delete it forever from the world. I'm happy to file the INFRA ticket to delete it, I'd just like to give everyone the opportunity to speak up in case there's

Re: [DISCUSS] Moving chats to ASF's Slack instance

2019-05-28 Thread Jon Haddad
+1 On Tue, May 28, 2019, 2:54 PM Joshua McKenzie wrote: > +1 to switching over. One less comms client + history + searchability is > enough to get my vote easy. > > On Tue, May 28, 2019 at 5:52 PM Jonathan Ellis wrote: > > > I agree. This lowers the barrier to entry for new participants.

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

2019-05-28 Thread Jon Haddad
Sept is a pretty long ways off. I think the ideal case is we can announce 4.0 release at the summit. I'm not putting this as a "do or die" date, and I don't think we need to announce it or make promises. Sticking with "when it's ready" is the right approach, but we need a target, and this is

Re: "4.0: TBD" -> "4.0: Est. Q4 2019"?

2019-05-28 Thread Jon Haddad
take as long > as 3.0 but want to know what is your thinking with this. > > Thanks, > Sankalp > > On Tue, May 28, 2019 at 9:40 AM Jon Haddad wrote: > > > Sept is a pretty long ways off. I think the ideal case is we can > announce > > 4.0 release at the sum

Re: Jira Suggestion

2019-05-14 Thread Jon Haddad
Great idea. +1 On Tue, May 14, 2019, 12:10 PM Benedict Elliott Smith wrote: > It will be possible to insert n/a. It will simply be a text field - Jira > doesn’t know anything about the concept of a SHA, and I don’t intend to > introduce validation logic. It’s just a logical and consistent

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-17 Thread Jon Haddad
ys do the afternoon. > > >> > > > >> > Cheers, > > >> > Anthony > > >> > > > >> > > > >> > On Sat, 13 Apr 2019 at 22:38, Stefan Miklosovic < > > >> > stefan.mikloso...@instaclustr.com> wr