Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 > On Feb 6, 2023, at 8:15 AM, Sam Tunnicliffe wrote: > > Hi everyone, > > I would like to start a vote on this CEP. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata > > Discussion: > https://lists.apache.org/thread/h25skwkbdztz9

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

+1 > On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa wrote: > > Hi Everyone! > > I would like to start a vote thread for CEP-34. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators > JIRA

Re: [VOTE] Release dtest-api 0.0.16

+1On Aug 17, 2023, at 12:37 AM, Alex Petrov wrote:+1On Thu, Aug 17, 2023, at 4:46 AM, Brandon Williams wrote:+1Kind Regards,BrandonOn Wed, Aug 16, 2023 at 4:34 PM Dinesh Joshi wrote:>> Proposing the test build of in-jvm dtest API 0.0.16 for release.>> Repository:> https://gitb

Re: [VOTE] Release Apache Cassandra 5.0-rc1

Looking at the ticket, I’d say Jon’s concern is legitimate. The segfaults Jon is seeing are probably caused by paxos V2 when combined with off heap memtables for the reason Benedict suggests in the JIRA. This problem will continue to exist in 5.0. Unfortunately, it looks like the patch posted is

Re: In need of reviewers

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: https://issues.apache.org

Re: Testing 4.0 Post-Freeze

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

Re: [VOTE] Release Apache Cassandra 2.2.13

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

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

+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 > > >), > if

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

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

Re: Proposing an Apache Cassandra Management process

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 w

Re: Side Car New Repo vs not

If the sidecar is going to be on a different release cadence, or support interacting with mixed mode clusters, then it should definitely be in a separate repo. I don’t even know how branching and merging would work in a repo that supports 2 separate release targets and/or mixed mode compatibilit

Re: Reaper as cassandra-admin

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 engi

Re: Reaper as cassandra-admin

pers already established around reaper 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

Re: Proposing an Apache Cassandra Management process

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 the

Re: Proposing an Apache Cassandra Management process

l 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 > features) in

Re: Proposing an Apache Cassandra Management process

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

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 solv

Re: JIRA Workflow Proposals

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

Re: [VOTE] Change Jira Workflow

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

Re: Modeling Time Series data

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

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

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 cur

Re: Stabilising Internode Messaging in 4.0

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 inaccurate

Re: Stabilising Internode Messaging in 4.0

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 leve

Time for a new 3.0/3.11 release?

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: fixing paging state for 4.0

Changing paging state format is kind of a pain since the driver treats it as an opaque blob. I'd prefer we went with Sylvain's suggestion to just interpret Integer.MAX_VALUE as "no limit", which would be a lot simpler to implement. > On Sep 24, 2019, at 10:44 AM, Jon Haddad wrote: > > I'm work

Re: Attention to serious bug CASSANDRA-15081

This looks like a dupe of CASSANDRA-15086, which has been committed and will be included in 3.0.19. > On Sep 11, 2019, at 5:10 PM, Cameron Zemek wrote: > > Have had multiple customer hit this CASSANDRA-15081 issue now, where > upgrading from older versions the sstables contain an unknown column

Re: fixing paging state for 4.0

ersion clusters or is there > something else that makes it a problem? > > On Tue, Sep 24, 2019 at 11:03 AM Blake Eggleston > wrote: > >> Changing paging state format is kind of a pain since the driver treats it >> as an opaque blob. I'd prefer we went with Sylvain&#x

Re: fixing paging state for 4.0

heir data. > Which realistically is probably what someone who sets the protocol level > query limit to Integer.MAX_VALUE is trying to do. > > -Jeremiah > >> On Sep 24, 2019, at 4:09 PM, Blake Eggleston >> wrote: >> >> Right, mixed version clusters.

Re: fixing paging state for 4.0

gt;> don’t support it. Or they will connect to the newer nodes with the older >>> protocol version. In either of those cases there is no problem. >>> >>> Protocol changes aside, I would suggest fixing the bug starting back on >>> 3.x by changing the

Re: fixing paging state for 4.0

Sorry, I misread your earlier email. Yes, there are drivers that do mixed protocol versions. Not sure if the 4.0 java driver does, but at least one previous version did. > On Sep 24, 2019, at 7:19 PM, Blake Eggleston > wrote: > > Yes, but if a client is connected to 2 different n

Re: Can we kick off a release?

Looks like 15193 has been committed. Are we waiting on anything else before cutting the next set of releases? > On Oct 8, 2019, at 1:11 PM, Jon Haddad wrote: > > I forgot to mention, we should also release alpha2 of 4.0. > > > On Tue, Oct 8, 2019 at 1:04 PM Michael Shuler > wrote: > >> Than

Re: [VOTE] Release Apache Cassandra 2.2.15

+1 > On Oct 25, 2019, at 8:57 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 24 Oct 2019, at 18:25, Michael Shuler wrote: >>> >>> I propose the following artifacts for release as 2.2.15. >>> >>> sha1: 4ee4ceea28a1cb77b283c7ce01

Re: [VOTE] Release Apache Cassandra 3.0.19

+1 > On Oct 25, 2019, at 8:58 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 24 Oct 2019, at 18:25, Michael Shuler wrote: >>> >>> I propose the following artifacts for release as 3.0.19. >>> >>> sha1: a81bfd6b7db3a373430b3c4e8f

Re: [VOTE] Release Apache Cassandra 3.11.5

+1 > On Oct 25, 2019, at 8:58 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Oct 25, 2019 at 7:18 AM Sam Tunnicliffe wrote: > >> +1 >> >>> On 24 Oct 2019, at 18:26, Michael Shuler wrote: >>> >>> I propose the following artifacts for release as 3.11.5. >>> >>> sha1: b697af87f8e1b20d22948390d5

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

+1 > On Oct 25, 2019, at 8:57 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Oct 25, 2019 at 8:06 AM Jon Haddad wrote: > >> +1 >> >> On Fri, Oct 25, 2019 at 10:18 AM Sam Tunnicliffe wrote: >> >>> +1 >>> On 24 Oct 2019, at 18:26, Michael Shuler >> wrote: I propose the followi

Re: [VOTE] Release Apache Cassandra 4.0-alpha4

+1 > On Apr 14, 2020, at 5:09 AM, e.dimitr...@gmail.com wrote: > > I also can’t see them. I think it matters to which interface is the link. > > And +1 from me, thanks! > >> On 14 Apr 2020, at 7:53, Erick Ramirez wrote: >> >>  >>> >>> All java8 UTs, jvmdtests and dtests pass >

Re: [VOTE] Project governance wiki doc (take 2)

+1 > On Jun 20, 2020, at 8:12 AM, Joshua McKenzie wrote: > > Link to doc: > https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance > > Change since previous cancelled vote: > "A simple majority of this electorate becomes the low-watermark for votes > in favour

Re: [DISCUSS] Future of MVs

+1 for deprecation and removal (assuming a credible plan to fix them doesn't materialize) > On Jun 30, 2020, at 12:43 PM, Jon Haddad wrote: > > A couple days ago when writing a separate email I came across this DataStax > blog post discussing MVs [1]. Imagine my surprise when I noticed the dat

Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)

I don't think Benedict mentioned anything about people's motives or intentions, he simply had a concern about how marketing timelines became a factor in a release vote without the approval of the PMC. I think this is a reasonable concern, and doesn't mean that he's assuming bad intentions. That'

Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)

Characterizing alternate or conflicting points of view as assuming bad intentions without justification is both unproductive and unhealthy for the project. > On Jul 20, 2020, at 9:14 AM, Joshua McKenzie wrote: > > This kind of back and forth isn't productive for the project so I'm not > taking

Re: [VOTE] Release Apache Cassandra 4.0-beta1 (take2)

+1 > On Jul 20, 2020, at 9:56 AM, Jon Haddad wrote: > > +1, thanks Mick for rerolling. > > On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie > wrote: > >> +1 >> >> On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wrote: >> >>> +1 >>> >>> On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña < >>> a

Check in on CASSANDRA-15393

Hi dev@, Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's some concern regarding the patch and it's suitability for inclusion in 4.0-beta. CASSANDRA-15393 reduces garbage created by compaction and the read paths by about 25%. It's part of CASSANDRA-15387, which, includi

Re: Check in on CASSANDRA-15393

landing? The later, the more risk to stability of > GA due to lack of time soaking. > > On Thu, Aug 27, 2020 at 4:01 PM Blake Eggleston > wrote: > >> Hi dev@, >> >> Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's >> some co

Re: [VOTE] Release Apache Cassandra 3.11.8

+1 > On Aug 28, 2020, at 6:37 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.11.8 for release. > > sha1: 8b29b698630960a0ebb2c695cc5b21dee4686d09 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.8-tentative > Maven Artifacts: > htt

Re: [VOTE] Release Apache Cassandra 2.2.18

+1 > On Aug 28, 2020, at 5:44 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 2.2.18 for release. > > sha1: d4938cf4e488a9ef3ac48164a3e946f16255d721 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.18-tentative > Maven Artifacts: > htt

Re: [VOTE] Release Apache Cassandra 2.1.22

+1 > On Aug 28, 2020, at 8:55 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Aug 28, 2020 at 8:42 AM Mick Semb Wever wrote: > >> Proposing the test build of Cassandra 2.1.22 for release. >> >> sha1: 94e9149c22f6a7772c0015e1b1ef2e2961155c0a >> Git: >> >> https://gitbox.apache.org/repos/asf?p=ca

Re: [VOTE] Release Apache Cassandra 3.0.22

+1 > On Aug 28, 2020, at 6:09 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.0.22 for release. > > sha1: 45331bb612dc7847efece7e26cdd0b376bd11249 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.22-tentative > Maven Artifacts: > htt

Re: [VOTE] Release Apache Cassandra 4.0-beta2

+1 > On Aug 28, 2020, at 7:18 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0-beta2 for release. > > sha1: 56eadf2004399a80f0733041cacf03839832249a > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta2-tentative > Maven Artifacts:

Re: [DISCUSS] Change style guide to recommend use of @Override

+1 > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > Currently our style guide recommends to avoid using @Override and updates > intellij's code style to exclude it by default; I would like to propose we > change this recommendation to use it and to update intellij's style to > include it

Re: [VOTE] Accept the Harry donation

+1 > On Sep 16, 2020, at 2:45 AM, Mick Semb Wever wrote: > > This vote is about officially accepting the Harry donation from Alex Petrov > and Benedict Elliott Smith, that was worked on in CASSANDRA-15348. > > The Incubator IP Clearance has been filled out at > http://incubator.apache.org/ip-cl

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

I’d also prefer #3 over #4 > On Nov 20, 2020, at 10:03 AM, Benedict Elliott Smith > wrote: > > Well, I expressed a preference for #3 over #4, particularly for the 3.x > series. However at this point, I think the lack of a clear project decision > means we can punt it back to you and Sylvain

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

for choosing correctness is easier to live with ;-) >> >> Benjamin >> >> PS: I tried to push the choice on Sylvain but he dodged the bullet. >> >> On Sat, Nov 21, 2020 at 12:30 AM Benedict Elliott Smith < >> bened...@apache.org> >> wrote: >>

Re: [VOTE] Release dtest-api 0.0.7

Proposing the test build of in-jvm dtest API 0.0.7 for release. Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.7 Candidate SHA:https://github.com/apache/cassandra-in-jvm-dtest-api/commit/d5174b1f44b7d9cb919d4975b4d437041273c09c tagged w

Re: [VOTE] Release dtest-api 0.0.7

+1, sorry for the html barf :) > On Dec 3, 2020, at 9:53 AM, Blake Eggleston > wrote: > > Proposing the test build of in-jvm dtest API 0.0.7 for > release. > > Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags

Re: [VOTE] Release Apache Cassandra 2.2.0-rc2

-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 wrote: > +1 non-binding > > On 07/06/2015 01:47 PM, Jake Luciani wrote: > > I propose the follow

CASSANDRA-9143

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

Re: CASSANDRA-9143

amming 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 : > >> Hi everyone, >> >> I just posted a proposed solution to some issues with incremental repair >> in

Re: Proposal - 3.5.1

 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 fulfil

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

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: Summary of 4.0 Large Features/Breaking Changes (Was: Rough roadmap for 4.0)

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

e to >> push >>>>> unfinished work into a release. >>>>> The disadvantage of a prod release every 6 months is then we either >> have >>>>> a very short lifespan per-release, or we have to maintain lots of >> active >>&g

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

d actually deploying it. However, you can be sure that any 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 > wrote: > >> I think E

Re: Proposals for releases - 4.0 and beyond

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 Podkowins

Re: Wrapping up tick-tock

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 supp

Re: [VOTE] 3.X branch feature freeze

+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: WriteTimeoutException when doing paralel DELETE IF EXISTS

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. Thanks,

Re: Dropped messages on random nodes.

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: Showing a new property in DESCRIBE TABLE output

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 as_

Re: Code quality, principles and rules

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 be

Can we kill the wiki?

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 r

Re: Can we kill the wiki?

The Cassandra wiki isn't used for collaborative design at all as far as I can tell. Also, most of the information that is in the wiki should probably be in tree somewhere. Either as proper docs, or contribution guidelines. On March 19, 2017 at 8:17:18 AM, Edward Capriolo (edlinuxg...@gmail.com)

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

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

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

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

Re: [DISCUSS] Implementing code quality principles, and rules (was: Code quality, principles and rules)

In addition to it’s test coverage problem, the project has a general testability problem, and I think it would be more effective to introduce some testing guidelines and standards that drive incremental improvement of both, instead of requiring an arbitrary code coverage metric be hit, which doe

Guidelines on testing

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 cou

Re: Guidelines on testing

/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 adding some

Re: Soliciting volunteers for flaky dtests on trunk

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 pr

Re: Repair Management

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 t

Re: Repair Management

and from StorageService::repairAsync . Hopefully the branch above shows what I am mean. On 19 May 2017 at 03:16, Blake Eggleston wrote: > I am looking to improve monitoring and management of repairs (so far I > have > patch for adding ActiveRepairs to table/keyspace metrics) and come ac

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

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

Proposal to retroactively mark materialized views experimental

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 production

Re: Proposal to retroactively mark materialized views experimental

gt;> Vinay Chella > > >> > > >>> On Fri, Sep 29, 2017 at 7:22 PM, Ben Bromhead > > wrote: > > >>> > > >>> I'm a fan of introducing experimental flags in general as well, +1 > > >>> > > >

Re: Proposal to retroactively mark materialized views experimental

re out how to restore the "new feature/community bug report" 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 wrote: > I'm not sure the main issue in the case of MVs is

Re: Proposal to retroactively mark materialized views experimental

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 emi

Re: Proposal to retroactively mark materialized views experimental

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 disabling

Re: Proposal to retroactively mark materialized views experimental

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

Re: Proposal to retroactively mark materialized views experimental

INDEX ON sasi_table (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 wro

Re: Proposal to retroactively mark materialized views experimental

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

Re: Cassandra pluggable storage engine (update)

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 the

Re: Reviewer for LWT bug

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: Expensive metrics?

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: A JIRA proposing a seperate repository for the online documentation

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. I'm not sure Hugo is the way

Repair scheduling tools

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

Re: Roadmap for 4.0

+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 on point - thanks, Scott! (And > g

Re: Roadmap for 4.0

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 i

Re: Repair scheduling tools

-compaction >> from >> > > repair anticompactions, and subrange repairs seem to eliminate this. >> Even >> > > if they didn't, a more direct method along the lines of "don't repair >> when >> > > the compact

Re: Cassandra + RAMP transactions

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, wrote: > Hi Jatin, > > I believe there is a lot of interest in developing RAMP transactions for > Cassandra, but no concre

Re: [VOTE] Release Apache Cassandra 4.0-rc1

+1 > On Mar 29, 2021, at 6:05 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0-rc1 for release. > > sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative > Maven Artifacts: > h

Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)

+1 > On Apr 21, 2021, at 2:25 PM, Scott Andreas wrote: > > +1nb, thank you! > > > From: Ekaterina Dimitrova > Sent: Wednesday, April 21, 2021 12:23 PM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2) > > +1

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 > On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko wrote: > > +1 > >> On 14 Jul 2021, at 15:37, Jonathan Ellis wrote: >> >> +1 >> >>> On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever wrote: >>> >>> Proposing the test build of Cassandra 4.0.0 for release. >>> >>> sha1: 924bf92fab182094213

  1   2   >