Time for a new 3.0/3.11 release?

2019-07-01 Thread Blake Eggleston
Hi dev@, Any objections to doing a new 3.0 and 3.11 release? Both branches have accumulated a decent number of changes since their last release, the highlights being improved merkle tree footprint, a gossip race, and a handful of 2.1 -> 3.x upgrade bugs. Thanks, Blake

Re: Stabilising Internode Messaging in 4.0

2019-04-12 Thread Blake Eggleston
It seems like one of the main points of contention isn’t so much the the content of the patch, but more about the amount of review this patch has/will receive relative to its perceived risk. If it’s the latter, then I think it would be more effective to explain why that’s the case, and what

Re: Stabilising Internode Messaging in 4.0

2019-04-12 Thread Blake Eggleston
Well said Josh. You’ve pretty much summarized my thoughts on this as well. +1 to moving forward with this > On Apr 11, 2019, at 10:15 PM, Joshua McKenzie wrote: > > As one of the two people that re-wrote all our unit tests to try and help > Sylvain get 8099 out the door, I think it's

Re: Both Java 8 and Java 11 required for producing a tarball

2019-03-13 Thread Blake Eggleston
You may want to wait until CASSANDRA-14607 is finished before starting on 14712. I think it will end up unwinding most of the stuff requiring building with dual jdks (either as part of that ticket or an immediate follow on). I'm still working on making sure I haven't broken anything, but I'm

Re: Modeling Time Series data

2019-01-11 Thread Blake Eggleston
This is a question for the user list. > On Jan 11, 2019, at 1:51 PM, Akash Gangil wrote: > > Hi, > > I have a data model where the partition key for a lot of tables is based on > time > (year, month, day, hour) > > Would this create a hotspot in my cluster, given all the writes/reads would >

Re: [VOTE] Change Jira Workflow

2018-12-17 Thread Blake Eggleston
+1 > On Dec 17, 2018, at 9:31 AM, jay.zhu...@yahoo.com.INVALID wrote: > > +1 > >On Monday, December 17, 2018, 9:10:55 AM PST, Jason Brown > wrote: > > +1. > > On Mon, Dec 17, 2018 at 7:36 AM Michael Shuler > wrote: > >> +1 >> >> -- >> Michael >> >> On 12/17/18 9:19 AM, Benedict

Re: JIRA Workflow Proposals

2018-12-04 Thread Blake Eggleston
1: A 2: +1 3: +1 4: +1 5: +1 6: +1 > On Dec 4, 2018, at 11:19 AM, Benedict Elliott Smith > wrote: > > Sorry, 4. Is inconsistent. First instance should be. > >> - 4. Priorities: Keep ‘High' priority > > >> On 4 Dec 2018, at 19:12, Benedict Elliott Smith > >

Re: Proposing an Apache Cassandra Management process

2018-09-12 Thread Blake Eggleston
Reading through the history Sankalp posted (I think it was originally posted by Joey?), I think part of the problem we’re having here is that we’re trying to solve at least 3 problems with a single solution. Also, I don’t think everyone has the same goals in mind. The issues we’re trying to

Re: Proposing an Apache Cassandra Management process

2018-09-07 Thread Blake Eggleston
t 6:53 PM, Blake Eggleston wrote: > > What’s the benefit of doing it that way vs starting with reaper and > integrating the netflix scheduler? If reaper was just a really inappropriate > choice for the cassandra management process, I could see that being a better > approach,

Re: Proposing an Apache Cassandra Management process

2018-09-07 Thread Blake Eggleston
and isolated and layering on top. -- Jeff Jirsa > On Sep 7, 2018, at 5:42 PM, Blake Eggleston wrote: > > I think we should accept the reaper project as is and make that cassandra > management process 1.0, then integrate the netflix scheduler (and other new

Re: Proposing an Apache Cassandra Management process

2018-09-07 Thread Blake Eggleston
I think we should accept the reaper project as is and make that cassandra management process 1.0, then integrate the netflix scheduler (and other new features) into that. The ultimate goal would be for the netflix scheduler to become the default repair scheduler, but I think using reaper as

Re: Reaper as cassandra-admin

2018-08-28 Thread Blake Eggleston
eaper is also a consideration. On August 28, 2018 at 3:53:02 PM, dinesh.jo...@yahoo.com.INVALID (dinesh.jo...@yahoo.com.invalid) wrote: On Tuesday, August 28, 2018, 2:52:03 PM PDT, Blake Eggleston wrote: > I’m sure reaper will bring tech debt with it, but I doubt it's a hopeless > mess

Re: Reaper as cassandra-admin

2018-08-28 Thread Blake Eggleston
I haven’t settled on a position yet (will have more time think about things after the 9/1 freeze), but I wanted to point out that the argument that something new should be written because an existing project has tech debt, and we'll do it the right way this time, is a pretty common software

Re: Proposing an Apache Cassandra Management process

2018-08-17 Thread Blake Eggleston
I'd be more in favor of making it a separate project, basically for all the reasons listed below. I'm assuming we'd want a management process to work across different versions, which will be more awkward if it's in tree. Even if that's not the case, keeping it in a different repo at this point

Re: [VOTE] Release Apache Cassandra 3.0.17 (Take 2)

2018-07-27 Thread Blake Eggleston
+1 On July 26, 2018 at 9:27:11 PM, Marcus Eriksson (krum...@gmail.com) wrote: +1 On Fri, Jul 27, 2018 at 5:03 AM Vinay Chella wrote: > +1 nb. > > Here are the test results. > https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.0.17_tentative > > Most of the failed tests are

Re: [VOTE] Release Apache Cassandra 2.2.13

2018-07-27 Thread Blake Eggleston
+1 On July 26, 2018 at 9:26:48 PM, Marcus Eriksson (krum...@gmail.com) wrote: +1 On Fri, Jul 27, 2018 at 12:05 AM kurt greaves wrote: > +1 nb > > On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe, wrote: > > > +1 > > > > On 25 July 2018 at 08:17, Michael Shuler wrote: > > > > > I

Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)

2018-07-27 Thread Blake Eggleston
+1 On July 26, 2018 at 9:27:27 PM, Marcus Eriksson (krum...@gmail.com) wrote: +1 On Fri, Jul 27, 2018 at 4:59 AM Vinay Chella wrote: > +1 nb. > > Here are the failed tests (circleci > < > https://circleci.com/gh/vinaykumarchella/workflows/cassandra/tree/3.11.3_tentative > > >), >

Re: Testing 4.0 Post-Freeze

2018-07-10 Thread Blake Eggleston
+1 from me as well. Let's try it out On 7/10/18, 11:23 AM, "Sam Tunnicliffe" wrote: +1 here too On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson wrote: > +1 here as well > > On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko > wrote: > > > +1 from me

Re: In need of reviewers

2018-05-11 Thread Blake Eggleston
I'll spend a day or two working through some of these next week. On 5/11/18, 3:44 AM, "kurt greaves" wrote: We've got a bunch of tickets that are either in need of review or just a bit of feedback. Would be very grateful for any help here :). Bugs:

Re: Repair scheduling tools

2018-04-16 Thread Blake Eggleston
g the lines of "don't repair >> when >> > > the compaction queue is too long" might make more sense. Blacklisted >> > > timeslots might be useful for avoiding peak time or batch jobs, but >> only if >> > > they can be spec

Re: Roadmap for 4.0

2018-04-11 Thread Blake Eggleston
I agree that not releasing semi-regularly is not good for the project. I think our habit of releasing half working software is much worse though. Our testing/stability story is not iron clad. I really think the bar for releasing 4.0 should be that the people in this thread are running the code

Re: Roadmap for 4.0

2018-04-04 Thread Blake Eggleston
+1 On 4/4/18, 5:48 PM, "Jeff Jirsa" wrote: Earlier than I’d have personally picked, but I’m +1 too -- Jeff Jirsa > On Apr 4, 2018, at 5:06 PM, Nate McCall wrote: > > Top-posting as I think this summary is

Repair scheduling tools

2018-04-03 Thread Blake Eggleston
Hi dev@, The question of the best way to schedule repairs came up on CASSANDRA-14346, and I thought it would be good to bring up the idea of an external tool on the dev list. Cassandra lacks any sort of tools for automating routine tasks that are required for running clusters,

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

2018-03-16 Thread Blake Eggleston
It would probably be more productive to list some specific concerns you have with Hugo. Then explain why you think they make using it a bad idea. Then offer some alternatives. On 3/16/18, 1:18 PM, "Kenneth Brotman" wrote: Thanks for that Eric Evans.

Re: Expensive metrics?

2018-02-22 Thread Blake Eggleston
Hi Micke, This is really cool, thanks for taking the time to investigate this. I believe the metrics around memtable insert time come in handy in identifying high partition contention in the memtable. I know I've been involved in a situation over the past year where we got actionable info from

Re: Reviewer for LWT bug

2017-12-19 Thread Blake Eggleston
I'll take it On December 17, 2017 at 3:48:04 PM, kurt greaves (k...@instaclustr.com) wrote: Need a reviewer for CASSANDRA-14087 Pretty straight forward, we just get an NPE when comparing against a frozen collection which is null and we

Re: Cassandra pluggable storage engine (update)

2017-10-04 Thread Blake Eggleston
Hi Dikang, Cool stuff. 2 questions. Based on your presentation at ngcc, it seems like rocks db stores things in byte order. Does this mean that you have code that makes each of the existing types byte comparable, or is clustering order implementation dependent? Also, I don't see anything in

Re: Proposal to retroactively mark materialized views experimental

2017-10-03 Thread Blake Eggleston
The remaining issues are: * There's no way to determine if a view is out of sync with the base table. * If you do determine that a view is out of sync, the only way to fix it is to drop and rebuild the view. * There are liveness issues with updates being reflected in the view. On October 3,

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Blake Eggleston
(c) USING 'org.apache.cassandra.index.sasi.SASIIndex'; Warnings : A SASI index was enabled for ‘ks.sasi_table'. SASI is still experimental, take extra caution when using it in production. cqlsh:ks> -Jeremiah > On Oct 2, 2017, at 5:05 PM, Blake Eggleston <beggles...@apple.com> wrote: &g

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Blake Eggleston
does emitting a native protocol warning reduce visibility during > the > > >> development process? If you run CREATE MV and cqlsh then prints out a > > >> giant warning statement about how it is an experimental feature I > think > > >> that is pretty visibl

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Blake Eggleston
Yeah, I'm not proposing that we disable MVs in existing clusters. On October 2, 2017 at 10:58:11 AM, Aleksey Yeshchenko (alek...@apple.com) wrote: The idea is to check the flag in CreateViewStatement, so creation of new MVs doesn’t succeed without that flag flipped. Obviously, just

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Blake Eggleston
Yeah I’m not sure that just emitting a warning is enough. The point is to be super explicit that bad things will happen if you use MVs. I would (in a patch release) disable MV CREATE statements, and emit warnings for ALTER statements and on schema load if they’re not explicitly enabled. Only

Re: Proposal to retroactively mark materialized views experimental

2017-10-01 Thread Blake Eggleston
strong feedback loop, we're going to face again the same issues and same debate in the future On Sun, Oct 1, 2017 at 5:30 PM, Blake Eggleston <beggles...@apple.com> wrote: > I'm not sure the main issue in the case of MVs is testing. In this case it > seems to be that there are some desi

Re: Proposal to retroactively mark materialized views experimental

2017-10-01 Thread Blake Eggleston
xperimental flags in general as well, +1 > > >>> > > >>> > > >>> > > >>>> On Fri, 29 Sep 2017 at 13:22 Jon Haddad <j...@jonhaddad.com> wrote: > > >>>> > > >>>> I’m very much +1 on this,

Proposal to retroactively mark materialized views experimental

2017-09-29 Thread Blake Eggleston
Hi dev@, I’d like to propose that we retroactively classify materialized views as an experimental feature, disable them by default, and require users to enable them through a config setting before using. Materialized views have several issues that make them (effectively) unusable in

Re: Proposal: Closing old, unable-to-repro JIRAs

2017-09-15 Thread Blake Eggleston
+1 to that On September 14, 2017 at 4:50:54 PM, Jeff Jirsa (jji...@gmail.com) wrote: There's a number of JIRAs that are old - sometimes very old - that represent bugs that either don't exist in modern versions, or don't have sufficient information for us to repro, but the reporter has gone

Re: Repair Management

2017-05-19 Thread Blake Eggleston
torageService::repairAsync . Hopefully the branch above shows what I am mean. On 19 May 2017 at 03:16, Blake Eggleston <beggles...@apple.com> wrote: > I am looking to improve monitoring and management of repairs (so far I > have > patch for adding ActiveRepairs to table/keysp

Re: Repair Management

2017-05-18 Thread Blake Eggleston
I am looking to improve monitoring and management of repairs (so far I have  patch for adding ActiveRepairs to table/keyspace metrics) and come across  ActiveRepairServiceMBean but this appears to be limited to incremental  repairs. Is there a reason for this The incremental repair stuff was just

Re: Soliciting volunteers for flaky dtests on trunk

2017-05-10 Thread Blake Eggleston
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

Re: Guidelines on testing

2017-05-05 Thread Blake Eggleston
apache.org/doc/latest/development/testing.html > Not sure if it would make sense to merge or create an additional document. > > > On 24.04.2017 18:13, Blake Eggleston wrote: > > About a month ago, in the ‘Code quality, principles and rules’ thread, > I’d proposed

Guidelines on testing

2017-04-24 Thread Blake Eggleston
About a month ago, in the ‘Code quality, principles and rules’ thread, I’d proposed adding some testing standards to the project in lieu of revisiting the idea of removing singletons. The idea was that we could drive incremental improvement of the test coverage and testability situation that

Re: [VOTE] Ask Infra to move github notification emails to pr@

2017-03-20 Thread Blake Eggleston
+1 On March 20, 2017 at 3:33:16 PM, Jeff Jirsa (jji...@gmail.com) wrote: There's no reason for the dev list to get spammed everytime there's a github PR. We know most of the time we prefer JIRAs for real code PRs, but with docs being in tree and low barrier to entry, we may want to accept

Re: [VOTE] Ask Infra to move github notification emails to commits@

2017-03-20 Thread Blake Eggleston
Maybe we should add p...@cassandra.apache.org or something and send them there? I don't subscribe to commits@ because it's too much email, I would be interested in being notified when a PR is opened though. On March 20, 2017 at 3:00:47 PM, Jeff Jirsa (jji...@gmail.com) wrote: There's no reason

Can we kill the wiki?

2017-03-17 Thread Blake Eggleston
With CASSANDRA-8700, docs were moved in tree, with the intention that they would replace the wiki. However, it looks like we’re still getting regular requests to edit the wiki. It seems like we should be directing these folks to the in tree docs and either disabling edits for the wiki, or just

Re: Code quality, principles and rules

2017-03-17 Thread Blake Eggleston
I think we’re getting a little ahead of ourselves talking about DI frameworks. Before that even becomes something worth talking about, we’d need to have made serious progress on un-spaghettifying Cassandra in the first place. It’s an extremely tall order. Adding a DI framework right now would

Re: Showing a new property in DESCRIBE TABLE output

2017-01-24 Thread Blake Eggleston
I haven't seen your implementation, but the likely cause of your problem is either that the new parameter isn't being sent over the client protocol, or that cqlsh is ignoring it. The cqlsh output of DESCRIBE TABLE seems to be generated by the TableMetadata class in the python driver (see the

Re: Dropped messages on random nodes.

2017-01-23 Thread Blake Eggleston
Hi Dikang, Do you have any GC logging or metrics you can correlate with the dropped messages? A 13 second pause sounds like a bad GC pause. Thanks, Blake On January 22, 2017 at 10:37:22 PM, Dikang Gu (dikan...@gmail.com) wrote: Btw, the C* version is 2.2.5, with several backported patches.

Re: WriteTimeoutException when doing paralel DELETE IF EXISTS

2017-01-23 Thread Blake Eggleston
Hi Jaroslav, That's pretty much expected behavior for the current LWT implementation, which has problems with key contention (the usage pattern you're describing here). Typically, you want to avoid having multiple clients doing LWT operations on the same partition key at the same time.

Re: [VOTE] 3.X branch feature freeze

2017-01-13 Thread Blake Eggleston
+1 On January 13, 2017 at 12:38:55 PM, Michael Shuler (mich...@pbandjelly.org) wrote: +1 to freeze with this clarified branch situation. -- Michael On 01/13/2017 11:53 AM, Aleksey Yeschenko wrote: > To elaborate further, under the current consensus there would be no 3.12 > release.

Re: Wrapping up tick-tock

2017-01-10 Thread Blake Eggleston
I agree that 3.10 should be the last tick-tock release, but I also agree with Jon that we shouldn't go back to yearly-ish releases. 6 months has come up several times now as a good cadence for feature releases, and I think it's a good compromise between the competing interests of long term

Re: Proposals for releases - 4.0 and beyond

2016-11-21 Thread Blake Eggleston
I really like Stefan's Ubuntu model (because of the LTS release), with Sylvain's suggestion a close second. Both because I think we should do a supported, non-dev release every 6 months, and release bug fixes for them for a at least a year. On November 19, 2016 at 10:30:02 AM, Stefan

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-20 Thread Blake Eggleston
ny bugs we find > will be fixed ASAP; we have many users counting on it. > > Thanks for listening, > > -Jason > > > On Sat, Nov 19, 2016 at 11:04 AM, Blake Eggleston <beggles...@apple.com> > wrote: > >> I think Ed's just using gossip 2.0 as a hyp

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-18 Thread Blake Eggleston
> While stability is important if we push back large "core" changes until later > we're just setting ourselves up to face the same issues later on In theory, yes. In practice, when incomplete features are earmarked for a certain release, those features are often rushed out, and not always fully

Re: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

2016-11-18 Thread Blake Eggleston
Introducing all of these in a single release seems pretty risky. I think it would be safer to spread these out over a few 4.x releases (as they’re finished) and give them time to stabilize before including them in an LTS release. The downside would be having to maintain backwards compatibility

Re: Proposal - 3.5.1

2016-09-16 Thread Blake Eggleston
 I'm not even sure it's reasonable to  expect from *any* software, and even less so for an open-source  project based on volunteering. Not saying it wouldn't be amazing, it  would, I just don't believe it's realistic. Postgres does a pretty good job of this. This sort of thinking is a self

Re: CASSANDRA-9143

2016-08-24 Thread Blake Eggleston
ppropriate to > avoid spamming those not interested, and only update here if there are new > developments in the ticket direction. > > 2016-08-24 18:35 GMT-03:00 Blake Eggleston <beggles...@apple.com>: > >> Hi everyone, >> >> I just posted a proposed

CASSANDRA-9143

2016-08-24 Thread Blake Eggleston
Hi everyone, I just posted a proposed solution to some issues with incremental repair in CASSANDRA-9143. The solution involves non-trivial changes to the way incremental repair works, so I’m giving it a shout out on the dev list in the spirit of increasing the flow of information here.

Re: [VOTE] Release Apache Cassandra 2.2.0-rc2

2015-07-08 Thread Blake Eggleston
-1. I've found some problems with 2.2 commit log replay in https://issues.apache.org/jira/browse/CASSANDRA-9749 that could lose data in some situations. On Wed, Jul 8, 2015 at 7:19 AM Michael Shuler mich...@pbandjelly.org wrote: +1 non-binding On 07/06/2015 01:47 PM, Jake Luciani wrote: I

Re: Cassandra + RAMP transactions

2015-02-09 Thread Blake Eggleston
I've been working on the epaxos implementation. You can take a look at the ticket here: https://issues.apache.org/jira/browse/CASSANDRA-6246 On Mon, Feb 9, 2015 at 8:51 PM, tups...@tupshin.com wrote: Hi Jatin, I believe there is a lot of interest in developing RAMP transactions for