Re: Cassandra 5+ JDK Minimum Compatibility Requirement

s that can't be touched. It never made sense to me to try to > bundle new features / bug fixes with improvements to code quality. > > Making the code more reliable should be a goal in itself, rather than a side > effect of other work. > > Jon > > > >

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

This seems like a cool feature that will be useful in future development work, but not something we should be proactively refactoring the project to make use of. On Fri, May 9, 2025, at 10:18 AM, Vivekanand Koya wrote: > I would say that https://openjdk.org/jeps/394 (instanceOf) aims to provide

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> Yes, you need to read the original row before the transaction begins in order > to get the initial state, but could be done at local one by the coordinator, > reading itself. The performance overhead of an additional, local one read > should be significantly less than a Paxos transaction that

Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses

As mutation tracking relates to existing backup systems that account for repaired vs unrepaired sstables, mutation tracking will continue to promote sstables to repaired once we know they contain data that has been fully reconciled. The main difference is that they won’t be promoted as part of a

Re: March 2025 project status update

Technically March, but Abe Ratnofsky was also added as a committer. Looks like the announcement for that was missed On Fri, Mar 7, 2025, at 10:45 AM, Josh McKenzie wrote: > Did you know I sometimes fail at email filtering? > > 4 new committers! FOUR. Welcome to Bernardo Botella Corbi as well! >

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

+1 On Sun, Mar 9, 2025, at 5:17 AM, Mick Semb Wever wrote: > Please vote on the acceptance of the Cassandra Cluster Manager (CCM) > and its IP Clearance: > https://incubator.apache.org/ip-clearance/cassandra-ccm.html > > All consent from original authors of the donation, and tracking of > collect

Re: March 2025 project status update

ahem, sorry looks like we're still waiting on something from Abe on that one. Nevermind for now :) On Fri, Mar 7, 2025, at 1:05 PM, Blake Eggleston wrote: > Technically March, but Abe Ratnofsky was also added as a committer. Looks > like the announcement for that was missed > &

Re: CEP-15 Update

perations PaxosV2 supports” or “performs as well or >>> better than PaxosV2 on [workload(s)]”? >>> >>> I understand waiting asks a lot of the authors in terms of baring the >>> burden of a more complex merge. But I think we also need to consider what >

Re: CEP-15 Update

at 18:15, Jon Haddad wrote: > >> > >> > > >> > >> > Very exciting! > >> > >> > > >> > >> > I have a client that's very interested in Accord, so I should have > >> > budget to dig into it, espec

Re: CEP-15 Update

orting ByteOrderPartitioner, and live migration > from/to Paxos is undergoing fine-tuning and validation; probably there are > some other things I am forgetting. > > Altogether the feature is fairly mature, despite these caveats. This is the > fruit of the labour of a long list

Re: [VOTE] CEP-45: Mutation Tracking

t 8:15 PM C. Scott Andreas > > >>> wrote: > > >>> > > >>> +1 > > >>> > > >>>> On Feb 5, 2025, at 2:50 PM, Alex Petrov wrote: > > >>> > > >>> > > >>> +1 > > >>> > >

Re: [VOTE] CEP-45: Mutation Tracking

Ok ok, I've jumped gun here, sorry, small off by 24 error. Please continue voting, and I'll be back tomorrow :D On Wed, Feb 5, 2025, at 1:49 PM, Blake Eggleston wrote: > The vote passes with 10 +1s (4 nb) and no -1. > > Thanks everyone! > > Blake > > On We

Re: [VOTE] CEP-45: Mutation Tracking

The vote passes with 10 +1s (4 nb) and no -1. Thanks everyone! Blake On Wed, Feb 5, 2025, at 1:07 PM, Jon Meredith wrote: > +1 (nb) > > On Tue, Feb 4, 2025 at 5:07 PM guo Maxwell wrote: >> +1 >> Dmitry Konstantinov 于2025年2月5日 周三上午6:04写道： >>> +1 (nb) >>> >>> On Tue, 4 Feb 2025 at 22:00, Abe Ra

[VOTE] CEP-45: Mutation Tracking

are at least 3 binding +1s and no binding vetoes. Thanks, Blake Eggleston

Re: [DISCUSS] CEP-45: Mutation Tracking

Hi dev@, Looks like it's been about 10 days since the last message here. Are there any other comments before I put it up for a vote? Thanks, Blake > On Jan 18, 2025, at 12:33 PM, Blake Eggleston wrote: > > That's an interesting idea. Basically allow for a window of unc

Re: [DISCUSS] Snapshots outside of Cassandra data directory

Somewhat tangential, but I’d like to see Cassandra provide a backup story that doesn’t involve making copies of sstables. They’re constantly rewritten by compaction, and intelligent backup systems often need to be able to read sstable metadata to optimize storage usage. An interface purpose bui

Re: [DISCUSS] Bracing style on trunk

gt; > > > > On Sat, Jan 18, 2025 at 12:32 PM Ekaterina Dimitrova <mailto:e.dimitr...@gmail.com>> wrote: >> I also do not see huge benefit in switching the style, honestly. And I see >> risks more than benefits. >> >> I also share Blake’s opinion that this wou

Re: Checkstyle as style contract for Cassandra

Let’s also keep in mind that this is a discussion about the pros and cons of automatic formatting. Everyone wants what’s best for the project, although they may have different views about how to get there. One person thinking we should use a tool does not make them lazy, nor does it affect the

Re: [DISCUSS] CEP-45: Mutation Tracking

t mutation id to a table every few >> seconds asynchronously > > For accord we will write reservation records in advance so we can guarantee > we don’t go backwards. That is, we will periodically declare a point eg 10s > in the future that on restart we will have to first let

Re: [DISCUSS] Bracing style on trunk

I lean pretty strongly towards -1 on this. If we were starting a new project, then yeah it would make sense. As an older project though, I don’t see any clear benefits for switching the style at this point, and can foresee it causing a lot of pain. Even if we were to wait for accord before going

Re: [DISCUSS] CEP-45: Mutation Tracking

o on restart. I’m sure this work can use the same feature, though I agree > with Blake it’s likely an unrealistic case in anything but adversarial test > scenarios. > >> On 17 Jan 2025, at 22:52, Blake Eggleston wrote: >> >>  >> Hi Jon, thanks for the excellent ques

Re: [DISCUSS] CEP-45: Mutation Tracking

#x27;m missing something. > > Bootstrap/topology changes - what about RF changes. I don't think TCM > currently handles that. Would it need to be added to make mutation tracking > work? Where would the metadata be stored to indicate preferred sources for > missing mutations? Would

Re: [DISCUSS] CEP-45: Mutation Tracking

self from peers >> proactively using the seekable commitlog. >> >> Can you explain the reason you prefer to reconcile on read? Having a >> consistent commitlog would solve so many problems like CDC, PITR, MVs >> etc. >> >> Jake >> >> On Thu, Ja

Re: [DISCUSS] CEP-45: Mutation Tracking

stent commitlog would solve so many problems like CDC, PITR, MVs > etc. > > Jake > > On Thu, Jan 16, 2025 at 12:13 PM Blake Eggleston wrote: >> >> I’ve been thinking about the paging atomicity issue. I think it could be >> fixed with mutation tracking and with

Re: [DISCUSS] CEP-45: Mutation Tracking

payload, so if the application is taking long enough between pages that the log has been truncated, we’d have to throw an exception. This is mostly just me brainstorming though, and wouldn’t be something that would be in a v1. > On Jan 9, 2025, at 2:07 PM, Blake Eggleston wrote: > > S

Re: [DISCUSS] CEP-45: Mutation Tracking

 >>>>> > It's true that we can't offer multi-page write atomicity without some >>>>> > sort of MVCC. There are a lot of common query patterns that don't >>>>> > involve paging though, so it's not like the benefit of fixing

Re: [DISCUSS] CEP-45: Mutation Tracking

>>> > In the case of read repair, since we are only reading and correcting the >>> > parts of a partition that we're reading and not the entire contents of a >>> > partition on each read, read repair can break our guarantee on partition >>> >

Re: [DISCUSS] CEP-45: Mutation Tracking

say guarantee. From the CEP: >>>>> >>>>> > In the case of read repair, since we are only reading and correcting >>>>> > the parts of a partition that we're reading and not the entire contents >>>>> > of a partition on each read, read repair can break

Re: [DISCUSS] CEP-45: Mutation Tracking

P which has the mutation. > > I've worked with users who have been surprised by this behavior, because > pagination happens transparently. > > So even without repair mucking things up, we're unable to fulfill this > promise except under the specific, ideal circumsta

[DISCUSS] CEP-45: Mutation Tracking

atacenters The CEP is linked here: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45%3A+Mutation+Tracking, but please keep the discussion on the dev list. Thanks! Blake Eggleston

Re: Capabilities

TCM was designed with a couple of very specific correctness-critical use cases in mind, not as a generic mechanism for everyone to extend. Its initial scope was for those use cases, but it’s potential for enabling more sophisticated functionality was one of its selling points and is l

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: [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] 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] 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: [DISCUSS] Removing support for java 8

efficient so that people on all > ends can progress with whatever they work on. Let’s talk to Mick and put down > the pin-points and assess the plan? How about that? > > On Mon, 29 Aug 2022 at 17:25, Blake Eggleston <mailto:beggles...@apple.com>> wrote: > Can you say som

Re: [DISCUSS] Removing support for java 8

we add 17, to avoid making extra work. > > Kind Regards, > Brandon > > On Mon, Aug 29, 2022 at 3:40 PM Blake Eggleston wrote: >> >> Sorry, I meant trunk, not 4.1 :) >> >>> On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: >>> >>> Hi al

Re: [DISCUSS] Removing support for java 8

Yes I'd seen the 11+17 thread, but didn't see anything about an explicit jdk8 removal (ie: removal from CI etc). Ekaterina informed me there was an earlier thread covering that though > On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: > > Hi all, I wanted to propose re

Re: [DISCUSS] Removing support for java 8

Sorry, I meant trunk, not 4.1 :) > On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: > > Hi all, I wanted to propose removing jdk8 support for 4.1. Active support > ended back in March of this year, and I believe the community has built > enough confidence in java 1

[DISCUSS] Removing support for java 8

Hi all, I wanted to propose removing jdk8 support for 4.1. Active support ended back in March of this year, and I believe the community has built enough confidence in java 11 to make it an uncontroversial change for our next major release. Let me know what you think. Thanks, Blake

Re: CEP-15 multi key transaction syntax

I think we’ve converged on a starting syntax. Are there any additional comments before I open a JIRA? > On Jun 16, 2022, at 10:33 AM, Blake Eggleston wrote: > > I think in any scenario where the same cell is updated multiple times, the > last one would win. The final result fo

Re: CEP-15 multi key transaction syntax

hmetic (that itself yields NULL) > > This is explicitly stipulated in ANSI SQL 92, in 6.12 expression>: > > General Rules > > 1) If the value of any simply contained in a > is the null value, then the result of > the is the null val

Re: CEP-15 multi key transaction syntax

Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a little trickier. Assigning null to a column seems ok, but we should raise an exception if they're doing math or something that expects a non-null value > On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith > wrote: >

Re: CEP-15 multi key transaction syntax

I see what you mean. We have the EXISTS/NOT EXISTS condition for explicitly checking for the existence of a row. One thing the old syntax did is how it handled references to columns that don't exist. Previously, if any column reference didn't resolve, the update wouldn't apply. With the new synt

Re: CEP-15 multi key transaction syntax

, this would simplify the initial implementation, and let feature requests and first hand experience inform where and how the syntax develops from there. Blake > On Jun 13, 2022, at 12:14 PM, Blake Eggleston wrote: > > Does the IF <...> ABORT simplify reasoning though? If you rest

Re: CEP-15 multi key transaction syntax

on't have a clear answer, but I would love hearing from people > on what they think. > > > Patrick > > > On Fri, Jun 10, 2022 at 12:07 PM bened...@apache.org > <mailto:bened...@apache.org> <mailto:bened...@apache.org>> wrote: > > This mi

Re: CEP-15 multi key transaction syntax

> IF q1.a != 1 ROLLBACK TRANSACTION > UPDATE tbl SET a = q1.a + 1 WHERE k = 1 AS q2 > COMMIT TRANSACTION > > This is less succinct, but might be more familiar to users. We could also > eschew the ability to read from UPDATE statements entirely in this scheme, as > this woul

Re: CEP-15 multi key transaction syntax

o single rows we are updating, so we could simply maintain a > collections of rows and upsert into them as we process the execution. Most > transactions won’t need it, I suspect, so we don’t need to worry about > perfect efficiency. > > > From: Blake Eggleston > Date: Tuesday, 7 J

Re: CEP-15 multi key transaction syntax

is I think highly desirable for user experience, but this > does complicate it a bit if we want to remain intuitive. > > > > > From: Blake Eggleston > Date: Monday, 6 June 2022 at 23:17 > To: dev@cassandra.apache.org > Subject: Re: CEP-15 multi key transaction syn

Re: CEP-15 multi key transaction syntax

Hi all, Thanks for all the input and questions so far. Glad people are excited about this! I didn’t have any free time to respond this weekend, although it looks like Benedict has responded to most of the questions so far, so if I don’t respond to a question you asked here, you can interpret t

CEP-15 multi key transaction syntax

Hi dev@, I’ve been working on a draft syntax for Accord transactions and wanted to bring what I have to the dev list to solicit feedback and build consensus before moving forward with it. The proposed transaction syntax is intended to be an extended batch syntax. Basically batches with selects,

Re: [DISCUSS] Mentoring newcomers

I’m happy to help out > On Nov 12, 2021, at 9:04 AM, Benjamin Lerer wrote: > > Hi everybody > > As discussed in the *Creating a new slack channel for newcomers* thead, a > solution to help newcomers engage with the project would be to provide a > list of mentors that newcomers can contact when

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 2. +1 3. +1 > On Oct 14, 2021, at 9:31 AM, bened...@apache.org wrote: > > Hi everyone, > > I would like to start a vote on this CEP, split into three sub-decisions, as > discussion has been circular for some time. > > 1. Do you support adopting this CEP? > 2. Do you support the transacti

Re: Tradeoffs for Cassandra transaction management

the way while a vote on CEP-15 seemed > imminent. But discussing this tradeoffs thread with Jonathan, he encouraged > me to say these points in my own words, so here we are. > > > On Sun, Oct 10, 2021 at 7:17 AM Blake Eggleston > mailto:beggles...@apple.com.invalid>> wrot

Re: Tradeoffs for Cassandra transaction management

Let’s get back on topic. Jonathan, in your opening email you stated that, in your view, the 2 main areas of tradeoff were: > 1. Is it worth giving up local latencies to get full global consistency? Now we’ve established that we don’t need to give up local latencies with Accord, which leaves:

Re: Tradeoffs for Cassandra transaction management

I want to avoid it also, but if we’re going to compare Accord against a hypothetical SQL feature that seems to lack design goals, or any clear ideas about how it might be implemented, I don’t think we can rule it out. > On Oct 11, 2021, at 6:02 AM, Jonathan Ellis wrote: > > On Sat

Re: Tradeoffs for Cassandra transaction management

1. Is it worth giving up local latencies to get full global consistency? Most LWT use cases use LOCAL_SERIAL. This isn’t a tradeoff that needs to be made. There’s nothing about Accord that prevents performing consensus in one DC and replicating the writes to others. That’s not in scope for the

Re: [DISCUSS] CEP-15: General Purpose Transactions

You could establish a lower timestamp bound and buffer transaction state on the coordinator, then make the commit an operation that only applies if all partitions involved haven’t been changed by a more recent timestamp. You could also implement mvcc either in the storage layer or for some perio

Re: [DISCUSS] CEP-15: General Purpose Transactions

Hi Jake, > 1. Will this effort eventually replace consistency levels in C*? I ask > because one of the shortcomings of our paxos today is > it can be easily mixed with non serialized consistencies and therefore > users commonly break consistency by for example reading at CL.ONE while > also > us

Re: [VOTE] Release Apache Cassandra 4.0.1

+1 > On Sep 1, 2021, at 4:54 AM, Sam Tunnicliffe wrote: > > Proposing the test build of Cassandra 4.0.1 for release. > > sha1: 6709111ed007a54b3e42884853f89cabd38e4316 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.1-tentative > Maven Artifacts: > http

Re: [VOTE] CEP-14: Paxos Improvements

+1 > On Aug 27, 2021, at 12:48 PM, bened...@apache.org wrote: > > Hi everyone, I’m proposing this CEP for approval. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements > Discussion: > https://lists.apache.org/thread.html/r1af3da2d875ef93479e387407

Re: [DISCUSS] Repair Improvement Proposal

+1 from me, any improvement in this area would be great. It would be nice if this could include visibility into repair streams, but just exposing the repair state will be a big improvement. > On Aug 25, 2021, at 5:46 PM, David Capwell wrote: > > Now that 4.0 is out, I want to bring up improvin

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

+1 > On Jul 27, 2021, at 9:21 PM, Scott Andreas wrote: > > +1 nb > > > From: Sam Tunnicliffe > Sent: Tuesday, July 27, 2021 12:54 AM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] CEP-10: Cluster and Code Simulations > > +1 > >> On 26 Jul 2021,

Re: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

+1 > On Jul 23, 2021, at 6:39 AM, Branimir Lambov > wrote: > > +1 > >> On Fri, Jul 23, 2021 at 4:15 PM Aleksey Yeschenko >> wrote: >> >> +1 >> On 23 Jul 2021, at 14:03, Joshua McKenzie wrote: >>> >>> +1 >>> >>> On Fri, Jul 23, 2021 at 8:07 AM Dinesh Joshi >> >>> wrote: >>> +

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

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-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 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 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: [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: [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: [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] 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] 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: [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 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 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 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: 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

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

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: 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: [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: [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: [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] 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 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 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: 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: 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: 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

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

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

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

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

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

  1   2   >