Re: Merging CEP-15 to trunk

> "hold the same bar for merges into a feature branch as trunk" I think this is the key point here. If a feature branch is being treated as if it was a release branch with respect to commits that go into it then there should be no need to “do extra review pre merge to trunk”. The feature branc

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

I think we need a DISCUSS thread at minimum for API changes. And for anything changing CQL syntax, I think a CEP is warranted. Even if it is only a small change to the syntax. > On Feb 2, 2023, at 9:32 AM, Patrick McFadin wrote: > > API changes are near and dear to my world. The scope of cha

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 nb > On Feb 6, 2023, at 10: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/h25skwkbd

Re: Downgradability

If we can get opt-in major format upgrades, as well as an offline sstabledowngrade tool, I think we have a good first step that would make downgrades possible. Given Jacek’s work on the sstable format API, and the work from Yuki and Claude on old formats, I think we are pretty close to having b

Re: Downgradability

We have multiple tickets about to merge that introduce new on disk format changes. I see no reason to block those indefinitely while we figure out how to do the on disk format downgrade stuff. -Jeremiah > On Feb 22, 2023, at 3:12 PM, Benedict wrote: > > Ok I will be honest, I was fairly sure

Re: Degradation of availability when using NTS and RF > number of racks

I agree with Paulo, it would be nice if we could figure out some way to make new NTS work correctly, with a parameter to fall back to the “bad” behavior, so that people restoring backups to a new cluster can get the right behavior to match their backups. The problem with only fixing this in a ne

Re: Degradation of availability when using NTS and RF > number of racks

e where a potentially > QUORUM-busting configuration is used. I think it would be a worse experience > to not warn and let the user discover later when they can't write at QUORUM. > > Cheers, > > Derek > > On Tue, Mar 7, 2023 at 9:32 AM Jeremiah D Jordan <mailto:jere

Re: [DISCUSS] Enhanced Disk Error Handling

It is actually more complicated than just removing the sstable and running repair. In the face of expired tombstones that might be covering data in other sstables the only safe way to deal with a bad sstable is wipe the token range in the bad sstable and rebuild/bootstrap that range (or wipe/re

Re: [DISCUSS] New dependencies with Chronicle-Queue update

Given we need to upgrade to support JDK17 it seems fine to me. The only concern I have is that some of those libraries are already pretty old, for example the most recent jna-platform is 5.13.0 and 5.5.0 is almost 4 years old. I think we should we use the most recent versions of all libraries

Re: [DISCUSS] Change the useage of nodetool tablehistograms

-1 on any change which breaks the previously documented usage. +1 any additions to what the tool can do without breaking previously documented behavior. > On Mar 16, 2023, at 7:42 AM, Josh McKenzie wrote: > > We could also consider augmenting the tool with new named arguments with the > functi

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

> As for precedent - we (including me) have done a lot of stupid shit over the > years on this project. Half the time “this is how we’ve historically done X” > to me is a strong argument to start doing things differently. This is one > such case. +1. I definitely agree that this is one area of

Re: [EXTERNAL] [DISCUSS] Next release date

Given the fundamental change to how cluster operations work coming from CEP-21, I’m not sure what freezing early for “extra QA time” really buys us? I wouldn’t trust any multi-node QA done pre commit. What “stabilizing” do we expect to be doing during this time? How much of it do we just have

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

I have concerns with the majority of this being in the sidecar and not in the database itself. I think it would make sense for the server side of this to be a new service exposed by the database, not in the sidecar. That way it can be able to properly integrate with the authentication and auth

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

he caveat from >> the released analytics library once we can properly test vnode support. >> If it helps, I can update the CEP to say something more like “Caveat: >> Currently untested with vnodes - work is ongoing to remove this limitation” >> if that helps? >> >>

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

here’s nothing preventing the solution from working with vnodes >>>> right now, and no assumptions about a 1:1 topology between a token and a >>>> node. However, we don’t, today, have the ability to test vnode support >>>> end-to-end. We are working towards that, how

Re: [DISCUSS] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

> One of the explicit goals of making an official sidecar project was to > try to make it something the project does not break compatibility with > as one of the main issues the third-party sidecars (that handle > distributed control, backup, repair, etc ...) have is they break > constantly because

Re: [POLL] Vector type for ML

> To be clear, I support the general agreement David and Jonathan seem to have > reached. +1 as well. > On May 3, 2023, at 3:07 PM, Caleb Rackliffe wrote: > > To be clear, I support the general agreement David and Jonathan seem to have > reached. > > On Wed, May 3, 2023 at 3:05 PM Caleb Rac

Re: [DISCUSS] The future of CREATE INDEX

If the consensus is that SAI is the right default index, then we should just change CREATE INDEX to be SAI, and legacy 2i to be a CUSTOM INDEX. > On May 9, 2023, at 4:44 PM, Caleb Rackliffe wrote: > > Earlier today, Mick started a thread on the future of our index creation DDL > on Slack: >

Re: [DISCUSS] The future of CREATE INDEX

> If we assume SAI is what we should use by default for the cluster, would it > make sense to allow > > CREATE INDEX [IF NOT EXISTS] [name] ON () > > But use a new yaml config that switches from legacy to SAI? > > default_2i_impl: sai > > For 5.0 we can default to “legacy” (new features disab

Re: [VOTE] CEP-29 CQL NOT Operator

+1 nb > On May 8, 2023, at 3:52 AM, Piotr Kołaczkowski wrote: > > Let's vote. > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-29%3A+CQL+NOT+operator > > Piotr Kołaczkowski > e. pkola...@datastax.com > w. www.datastax.com

Re: [DISCUSS] The future of CREATE INDEX

> [POLL] Centralize existing syntax or create new syntax? 1.) CREATE INDEX ... USING WITH OPTIONS... > [POLL] Should there be a default? (YES/NO) YES > [POLL] What do do with the default? 3.) YAML config to override default index (legacy 2i remains the default) DESCRIBE should always s

Re: [DISCUSS] Feature branch version hygiene

So what do we do with feature branch merged tickets in this model? They stay on 5.0-target after close and move to 5.0.0 when the epic is merged and closes? > On May 18, 2023, at 9:33 AM, Josh McKenzie wrote: > >> My mental model, though, is that anything that’s not a concrete release >> numb

Re: Vector search demo, and query syntax

At first I wasn’t sure about using ORDER BY, but the more I think about what is actually going on, I think it does make sense. This also matches up with some ideas that have been floating around about being able to ORDER BY a sorted SAI index. -Jeremiah > On May 22, 2023, at 2:28 PM, Jonathan

Re: Evolving the client protocol

The protocol does already support optional/custom payloads to do such things. IIRC the zipkin tracing implementation https://github.com/thelastpickle/cassandra-zipkin-tracing for example uses this to pass the zipkin id to the server. > On Apr 20, 2018, at 1:02 PM, Max C. wrote: > > For thing

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

The community of people doing python development and the community of people running Cassandra servers are not the same. I am not fine riding the coat tails of libraries used in python development. As others have stated we need to be following the lead of the OS vendors that people will be dep

Re: GitHub PR ticket spam

Oh nice. I like the idea of keeping it but moving it to the worklog tab. +1 on that from me. > On Aug 6, 2018, at 5:34 AM, Stefan Podkowinski wrote: > > +1 for worklog option > > Here's an example ticket from Arrow, where they seem to be using the > same approach: > https://urldefense.proofp

Re: Proposing an Apache Cassandra Management process

Not sure why the two things being in the same repo means they need the same release process. You can always do interim releases of the management artifact between server releases, or even have completely decoupled releases. -Jeremiah > On Aug 17, 2018, at 10:52 AM, Blake Eggleston wrote: > >

Re: Side Car New Repo vs not

I think the following is a very big plus of it being in tree: >> * Faster iteration speed in general. For example when we need to add a >> new >> JMX endpoint that the sidecar needs, or change something from JMX to a >> virtual table (e.g. for repair, or monitoring) we can do all changes >> includi

Re: UDF

Be careful when pulling in source files from the DataStax Java Driver (or anywhere) to make sure and respect its Apache License, Version 2.0 and keep all Copyright's etc with said files. -Jeremiah > On Sep 11, 2018, at 12:29 PM, Jeff Jirsa wrote: > > +1 as well. > > On Tue, Sep 11, 2018 at 1

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

+1 But I also think getting this through incubation might take a while/be impossible given how large the contributor list looks… > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa wrote: > > +1 > > (Incubation looks like it may be challenging to get acceptance from all > existing contributors, thoug

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

No, doesn’t change it. Any code donation has to go through the incubation process, which is where all the legal stuff about it being donated is handled. This would be like the dtest repo which was donated a little while back, and followed this same process. -Jeremiah > On Sep 12, 2018, at 3:

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

gt;>>>>> generally skeptical that augmenting the scope of a project makes it >>>>> better: >>>>>> I feel >>>>>> keeping this project focused on the core server is better. I see >> risks >>>>>> here, but >&g

Re: Moving tickets out of 4.0 post freeze

So as to not confuse people, even if we never put out a 4.1, I think we should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x. And yes our .. versioning of the past never followed semver. -Jeremiah > On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith > wrote: > > I’d like to propose we d

Re: Deprecating/removing PropertyFileSnitch?

As long as we are correctly storing such things in the system tables and reading them out of the system tables when we do not have the information from gossip yet, it should not be a problem. (As far as I know GPFS does this, but I have not done extensive code diving or testing to make sure all

Re: Deprecating/removing PropertyFileSnitch?

ll be missing from gossip/system.peers? >>>>>>> >>>>>>> Em sáb, 20 de out de 2018 às 00:34, Sankalp Kohli < >>>>>> kohlisank...@gmail.com> >>>>>>> escreveu: >>>>>>> >>>>>>>&g

Re: Deprecating/removing PropertyFileSnitch?

hli wrote: > > No worries...I mentioned the issue not the JIRA number > >> On Oct 22, 2018, at 8:01 PM, Jeremiah D Jordan wrote: >> >> Sorry, maybe my spam filter got them or something, but I have never seen a >> JIRA number mentioned in the thread before thi

Re: Audit logging to tables.

AFAIK the Full Query Logging binary format was already made more general in order to support using that format for the audit logging. -Jeremiah > On Mar 1, 2019, at 11:38 AM, Joshua McKenzie wrote: > > Is there a world in which a general purpose, side-channel file storage > format for transien

Re: [Discuss] num_tokens default in Cassandra 4.0

+1 for 8 + algorithm assignment being the default. Why do we have to assume random assignment? If someone turns off algorithm assignment they are changing away from defaults, so they should also adjust the num tokens. -Jeremiah > On Feb 18, 2020, at 1:44 AM, Mick Semb Wever wrote: > > -1 >

Re: Simplify voting rules for in-jvm-dtest-api releases

I think as long as we don’t publish the artifacts to maven central or some other location that is for “anyone” we do not need a formal release. Even then since the artifact is only meant for use by people developing C* that might be fine. If artifacts are only for use by individuals actively pa

Re: [DISCUSS] CASSANDRA-13994

+1 strongly agree. If we aren’t going to let something go into 4.0.0 because it would "invalidate testing” then we can not let such a thing go into 4.0.1 unless we plan to re-do said testing for the patch release. > On May 27, 2020, at 1:31 PM, Benedict Elliott Smith > wrote: > > I'm being t

Re: [DISCUSS] CASSANDRA-13994

d be >> thrilled. >> >> This is mostly a way of saying: >> – I like the cadence/sequencing Benedict proposes below. >> – I think improvements in test engineering can reduce/eliminate >> invalidation and may increase the scope of what can be a candidate for >

Re: [VOTE] Project governance wiki doc

+1 non-binding. Thanks for the work on this! > On Jun 16, 2020, at 11:31 AM, Jeff Jirsa wrote: > > +1 (pmc, binding) > > > On Tue, Jun 16, 2020 at 9:19 AM Joshua McKenzie > wrote: > >> Added unratified draft to the wiki here: >> >> https://cwiki.apache.org/confluence/display/CASSANDRA/Apac

Re: [VOTE] Project governance wiki doc

I think we need to assume positive intent here. If someone says they will participate then we need to assume they are true to their word. While the concerns are not un-founded, I think the doc as is gives a good starting point for trying this out without being too complicated. If this turns o

Re: [DISCUSS] Future of MVs

> So from my PoV, I'm against us just voting to deprecate and remove without > going into more depth into the current state of things and what options are > on the table, since people will continue to build MV's at the client level > which, in theory, should have worse correctness and performance

Re: [DISCUSS] CEP-7 Storage Attached Index

> Short question: looking forward, how are we going to maintain three 2i > implementations: SASI, SAI, and 2i? I think one of the goals stated in the CEP is for SAI to have parity with 2i such that it could eventually replace it. > On Sep 23, 2020, at 10:34 AM, Oleksandr Petrov > wrote: > >

Re: Welcome Jordan West, David Capwell, Zhao Yang and Ekaterina Dimitrova as Cassandra committers

Congratulations everyone! Good to see the project getting new committers. > On Dec 16, 2020, at 10:55 AM, Benjamin Lerer > wrote: > > The PMC's members are pleased to announce that Jordan West, David Capwell, > Zhao Yang and Ekaterina Dimitrova have accepted the invitations to become > committ

Re: [DISCUSS] Releases after 4.0

I think we are confusing things between minor vs patch. Can we talk about branch names? I think we can agree on the following statements? Releases made from stable maintenance branches, cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit features being added to them and shou

Re: March 2015 QA retrospective

CASSANDRA-8687 > Jeremiah Jordan > Keyspace > should also check Config.isClientMode Is there a way to test for missing > Config.isClientMode checks? We should probably redo the client mode type stuff. Code should assume we are in a tool unt

Re: Staging Branches

"Our process is our own" <- always remember this. > On May 7, 2015, at 9:25 AM, Ariel Weisberg > wrote: > > Hi, > > Whoah. Our process is our own. We don't have to subscribe to any cargo cult > book buying seminar giving process. > > And whatever we do we can iterate and change until it works

Re: Requiring Java 8 for C* 3.0

With Java 7 being EOL for free versions I am +1 on this. If you want to stick with 7, you can always keep running 2.1. > On May 7, 2015, at 11:09 AM, Jonathan Ellis wrote: > > We discussed requiring Java 8 previously and decided to remain Java > 7-compatible, but at the time we were planning t

Re: Cassandra Java Driver and DataStax

The Apache Cassandra project has always left development of its drivers up to the community. The DataStax Java Driver is not part of the Apache Cassandra project, it is an open source project created by DataStax. You can find a large list of drivers for Cassandra here: https://wiki.apache.org

Re: Reminder: critical fixes only in 2.1

Looking at those tickets in all three of them the “is this critical to fix” question came up in the JIRA discussion and it was decided that they were indeed critical enough to commit to 2.1. > On Jul 18, 2016, at 11:47 AM, Jonathan Ellis wrote: > > We're at the stage of the release cycle where

Re: State of Unit tests (1 out of 100 passes in trunk)

> Josh, add me to the "test fixers" queue, as well. However, I think the > authors of patches that break the build should also be on the hook for > fixing problems, as well. +1 I have always been a fan of “you broke it, you fix it"

Re: DSE vs Open Source

Hi John, I work for the DSE team. What you're seeing is the result of DSE having its own release schedule distinct from Apache Cassandra. We'll start qualifying an Apache release to build on, such as 3.0.7 for DSE 5.0, but if 3.0.8 comes out while we're still working on 5.0.1 we won't necessa

Re: A proposal to move away from Jira-centric development

I like keeping things in JIRA because then everything is in one place, and it is easy to refer someone to it in the future. But I agree that JIRA tickets with a bunch of design discussion and POC’s and such in them can get pretty long and convoluted. I don’t really like the idea of moving all of

Re: A proposal to move away from Jira-centric development

d be sufficient to announce those major JIRAs on > the dev@ list, but keep all discussion itself to JIRA, where it belongs. > >You don’t need to follow every ticket this way, just subscribe to dev@ and > then start watching the select major JIRAs you care about. > >

Re: A proposal to move away from Jira-centric development

ool >>> like Jira comes in. Then it is reference-able in the changes.txt and other >>> things. >>> >>> I think the approach proposed by Jonathan is a nice way to keep dev >>> list followers informed but keeping ticket details focused. >>> >>>> O

Re: A proposal to move away from Jira-centric development

Back to the topic at hand. First, let us establish that all of this stuff will be happening “on the mailing lists”, all JIRA updates are sent to commits@ with the reply-to set to dev@, so “JIRA” is still “on the list". Now we just need to decide how we would like to best make use of these lists

A proposal to get dev@ more involved

The original thread I posted this in got hi-jacked with other discussions, so I’m making a new thread for this. People have expressed interest in having more information flow to the dev@ list about major features/decisions, so that those who don’t follow commits@ or JIRA can still keep up with

Re: Github pull requests

+1 for PR’s but if we start using them I think we should get them sent to commits@ instead of the dev@ they are currently sent to. -Jeremiah > On Aug 26, 2016, at 1:38 PM, Andres de la Peña wrote: > > +1 to GitHub PRs, I think it will make things easier. > > El viernes, 26 de agosto de 2016,

Re: #cassandra-dev IRC logging

Also just to make sure, this is logging for #cassandra-dev not #cassandra right? -Jeremiah > On Aug 30, 2016, at 3:11 PM, Jeff Jirsa wrote: > > http://wilderness.apache.org/channels/ > > > > On 8/30/16, 1:04 PM, "Jonathan Ellis"

Re: Gossip 2.0

He denied it when I asked him that earlier. But we know he did. http://wilderness.apache.org/channels/?f=cassandra-dev/2016-09-01#1472732219 > On Sep 1, 2016, at 11:02 AM, Eric Evans wrote: > > On Thu, Sep 1, 2016 a

Re: Proposal - 3.5.1

I’m with Jeff on this, 3.7 (bug fixes on 3.6) has already been released with the fix. Since the fix applies cleanly anyone is free to put it on top of 3.5 on their own if they like, but I see no reason to put out a 3.5.1 right now and confuse people further. -Jeremiah > On Sep 15, 2016, at 9

Re: Proposal - 3.5.1

rior to >>> upgrading, and I don’t think it’s reasonable to ask users to recompile a >>> release for a ~10 line fix for a very nasty bug. >>> >>> I’m also very strongly recommend we (committers/PMC) reconsider tick/tock >>> for 4.x

Re: sstableloader from java

Yes using the SSTableLoader class. You can see the CqlBulkRecordWriter class for an example of writing out sstables to disk and then using the SSTableLoader class to stream them to a cluster. -Jeremiah > On Sep 21, 2016, at 7:18 PM, Paul Weiss wrote: > > Hi, > > Is it possible to call the s

Re: Proprietary Replication Strategies: Cassandra Driver Support

What kind of support are you thinking of? All drivers should support them already, drivers shouldn’t care about replication strategy except when trying to do token aware routing. But since anyone can make a custom replication strategy, drivers that do token aware routing just need to handle fal

Re: [jira] [Commented] (CASSANDRA-12490) Add sequence distribution type to cassandra stress

I would guess Jake replied to the JIRA message that was sent to commits@ expected the reply to end up going back to the ticket (which happens if you reply to something JIRA sends directly to you because you watched the ticket), but instead went to dev@ because the emails sent to commits@ from JI

Re: Low hanging fruit crew

Unless the reviewer reviews the for content, then you don’t know if they do or not. -Jeremiah > On Oct 19, 2016, at 10:52 AM, Jonathan Haddad wrote: > > Shouldn't the tests test the code for correctness? > > On Wed, Oct 19, 2016 at 8:34 AM Jonathan Ellis wrote: > >> On Wed, Oct 19, 2016 at

Re: Proposal - 3.5.1

My thinking was we keep doing tick/tock for the 4.x. Basically continue on for 4.0.x / 4.x like we have been with 3.0.x / 3.x, just with some added guidance to people that 4.x is “development releases”. The main problem I hear with the tick tock stuff is that we won’t ever have “LTS” branches

Re: Proposals for releases - 4.0 and beyond

I think the monthly releases are important, otherwise releases become an “event”. The monthly releases mean they are just a normal thing that happens. So I like any of 3/4/5. Sylvain's proposal sounds interesting to me. My only concern would be with making sure we label things very clearly s

Re: Collecting slow queries

Per the Fix Version on the ticket it is going to be in 3.10 when that is released. Probably in the next week provided we don’t find any more show stopper bugs. -Jeremiah > On Dec 6, 2016, at 10:38 AM, Jan wrote: > > Hello Yoshi-san; > is this fix rolled into Cassandra 3.7.0 ? I do not see

Re: Perf regression between 2.2.5 and 3.11

You may be getting perf issues from message coalescing depending on what CL you are testing with: https://issues.apache.org/jira/browse/CASSANDRA-12676 Try you tests with: otc_coalescing_strategy: DISABLED > On Jan 19, 2017, at 4:28 PM, Andrew Whang wrote: > > Hi, > > I'm seeing perf regressi

Re: Way to unsubscribe from mailing lists

It already sets those: List-Help: List-Unsubscribe: List-Post: List-Id: > On Apr 27, 2017, at 10:43 AM, Eric Evans wrote: > > On Wed, Apr 26, 2017 at 11:16 AM, Jake Luciani

Re: Integrating vendor-specific code and developing plugins

> On May 15, 2017, at 6:57 PM, 大平怜 wrote: > > Thanks for the discussion, all, > >>> * What's included when shipped in tree? >>> >>> Does every idea get merged in? Do we need 30 different Seed providers? Who >>> judges what's valuable enough to add? Who maintains it when it needs >>> updating

Re: Potential block issue for 3.0.13: schema version id mismatch while upgrading

If 3.0.13 causes schema mismatch on upgrade, then maybe we should pull that and release 3.0.14 once 13559 is fixed. As that is a pretty bad place to get into. > On May 30, 2017, at 6:39 PM, Jay Zhuang wrote: > > Seems the mail is marked as spam. So try forwarding with another email > account.

Re: Is concurrent_batchlog_writes option used/implemented?

The project hosted docs can be found here: http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html If you find something wrong in those open a JIRA. DataStax has a documentation feedback pag

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

> On Jul 31, 2017, at 12:17 PM, Jeff Jirsa wrote: > On 2017-07-29 10:02 (-0700), Jay Zhuang wrote: >> Should we consider back-porting it to 3.0 for the community? I think >> this is a performance regression instead of new feature. And we have the >> feature in 2.1, 2.2. >> > > Personally / in

Re: Compact Storage and SuperColumn Tables in 4.0/trunk

I think that all the work to support Compact Storage tables from CQL seems like wasted effort if we are going to tell people “just kidding, you have to migrate all your data”. I do not think supporting “COMPACT STORAGE” as a table option matters one way or the other. But I do think being able

Re: Proposal to retroactively mark materialized views experimental

Hindsight is 20/20. For 8099 this is the reason we cut the 2.2 release before 8099 got merged. But moving forward with where we are now, if we are going to start adding some experimental flags to things, then I would definitely put SASI on this list as well. For both SASI and MV I don’t know

Re: Proposal to retroactively mark materialized views experimental

ck the flag in CreateViewStatement, so creation of new MVs > doesn’t succeed without that flag flipped. > > Obviously, just disabling existing MVs working in a minor would be silly. > > As for the warning - yes, that should also be emitted. Unconditionally. > > — &

Re: [VOTE] Release Apache Cassandra 3.11.1

Jeff, TL;DR 3.11.0 shows it for them as well. See https://issues.apache.org/jira/browse/CASSANDRA-13900 for the rest of the story. -Jeremiah > On Oct 2, 2017, at 4:47 PM, Jeff Jirsa wrote: > > Thomas, did you see this on 3.11.0 as wel

Re: Proposal to retroactively mark materialized views experimental

atch release) disable MV CREATE statements, and emit >>>> warnings for ALTER statements and on schema load if they’re not >>> explicitly >>>> enabled" >>>> >>>> --> I find this pretty extreme. Now we have an e

Re: Proposal to retroactively mark materialized views experimental

Thanks for bringing this up Kurt, it is a fair point. Given the work that Paulo and Zhao have done to get MV’s in shape, what are the outstanding issues that would warrant making them experimental? > On Oct 3, 2017, at 5:56 AM, kurt greaves wrote: > > And finally, back onto the original top

Re: Proposal to retroactively mark materialized views experimental

So for some perspective here, how do users who do not get the guarantees of MV’s implement this on their own? They used logged batches. Pseudo CQL here, but you should get the picture: If they don’t ever update data, they do it like so, and it is pretty safe: BEGIN BATCH INSERT tablea blah INSE

Re: V5 as a protocol beta version in 3.11

My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol for tick/tock stuff and known that when a new version came out it would most possibly break the older releases V5 beta stuff? Or at the very least add new things to V5. So I see no reason to need to add more new features to

Re: URGENT: CASSANDRA-14092 causes Data Loss

If you aren’t getting an error, then I agree, that is very bad. Looking at the 3.0 code it looks like the assertion checking for overflow was dropped somewhere along the way, I had only been looking into 2.1 where you get an assertion error that fails the query. -Jeremiah > On Jan 25, 2018, a

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

I don’t think we need to stop the vote. This CVE has been around for a while (3/13/2017), and does affect any install I have ever seen. It affects users who manually enable some specific logback features using the SocketServer or ServerSocketReceiver component which are not used in our default

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

s/does affect/does not affect/ > On Feb 13, 2018, at 11:57 AM, Jeremiah D Jordan > wrote: > > I don’t think we need to stop the vote. This CVE has been around for a while > (3/13/2017), and does affect any install I have ever seen. It affects users > who manually en

Re: Expensive metrics?

re: nanoTime vs currentTimeMillis there is a good blog post here about the timing of both and how your choice of Linux clock source can drastically effect the speed of the calls, and also showing that in general on linux there is no perf improvement for one over the other. http://pzemtsov.github

Re: Debug logging enabled by default since 2.2

People seem hung up on DEBUG here. The goal of CASSANDRA-10241 was to clean up the system.log so that it a very high “signal” in terms of what was logged to it synchronously, but without reducing the ability of the logs to allow people to solve problems and perform post mortem analysis of issues

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

> Stefan's elastic search link is rather interesting. Looks like they are > compiling for both a LTS version as well as the current OpenJDK. They > assume some of their users will stick to a LTS version and some will run > the current version of OpenJDK. > > While it's extra work to add JDK versio

Re: Paying off tech debt and correctly naming things

+1 if you are willing to take it on. As the person who performed the Table->Keyspace rename of 2.0, I say good luck! From hindsight of doing that, as others suggested, I would come at this in multiple tickets. I would suggest a simple class rename with intellij refactoring tools or something a

Re: Submit enhancements via pull requests?

JIRA + patch or link to git branch -Jeremiah On Dec 5, 2013, at 9:44 AM, Brian O'Neill wrote: > > Sorry guys, it¹s been a while since I submitted a patch. > > I see there are a number of outstanding pull requests: > https://github.com/apache/cassandra/pulls > > Are we able to submit enhancem

Re: CQL unit tests vs dtests

The only thing I worry about here is that the unit tests don't come into the system the same way user queries will. So we still need the system level dtests. So I don't think all CQL tests should be unit tests, but I am all for there being unit level CQL tests. On May 22, 2014, at 10:58 AM, S

Re: [VOTE] Release Apache Cassandra 2.0.10

I'm -1 on this until we get CqlRecordReader fixed (which will also fix the newly added in 2.0.10 Pig CqlNativeStoarge): https://issues.apache.org/jira/browse/CASSANDRA-7725 https://issues.apache.org/jira/browse/CASSANDRA-7726 Without those two things anyone using CqlStorage previously (which remo

Re: [DISCUSS] Semantic versioning after 4.0

+1 for doing this (or something similar). It will give more clarity to downstream users about the compatibility of a given release. -Jeremiah > On Apr 30, 2021, at 12:45 PM, Mick Semb Wever wrote: > > *** Proposal *** > Aligned to the agreed-upon annual cadence of supported releases, let's >

Re: [DISCUSSION] Should we mark DROP COMPACT STORAGE as experimental

We had many discussions around this back when this was added. There is a transition ability in place. Users can set a native protocol flag to have the server return results as if DROP COMPACT STORAGE was already run. In this way you can update your applications to support the new way results

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

I tend to agree with Paulo that a major refactoring of some internal interfaces sounds like something to be explicitly avoided in a patch release. I thought this was the type of change we all agreed we should stop letting in to patch releases, and that we would attempt to release more often (on

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

only would it be burdensome (given the divergences in > the codebase), but I would not consider it acceptably safe (given the > divergence). > > > From: Jeremiah D Jordan > Date: Tuesday, 13 July 2021 at 14:15 > To: Cassandra DEV > Subject: Re: [DISCUSS] CEP-10: Clust

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

Too many nots. I do not think fixing 12126 is a new feature. > On Jul 13, 2021, at 8:40 AM, Jeremiah D Jordan wrote: > > I do not think fixing CASSANDRA-12126 is not a new feature. I do think > adding the ability to do “Cluster and Code Simulations” is a new feature. > >

  1   2   >