Re: [VOTE] Simplifying our release versioning process

> Also, I thought we had separate discussion about them - that we want to keep > up possibly with the last two LTS versions. This is what I remember as well. 6.0 would support 17/21 as thats the latest, if 7.0 is out before 25, then 7.0 would be 17/21, else it would be 21/25 > On Apr 23, 2025,

Re: [DISCUSS] How we version our releases

a software like > this, even that case doesn't really give me much heartburn. We shouldn't do > that of course, but even that extreme doesn't seem like it'd cause too much > pain. > > On Thu, Apr 17, 2025, at 2:53 PM, David Capwell wrote: >>> Does it me

Re: CEP-15 Update

; >>>>>>>>> >> >>>>>>>>> >> > On Tue, Mar 4, 2025 at 9:57 AM Dmitry Konstantinov >>>>>>>>> >> > mailto:netud...@gmail.com>> wrote: >>>>>>>>> >> >>&g

Re: [DISCUSS] How we version our releases

> Does it mean that one has to flag a feature as deprecated in the unreleased > version N, wait until when N is released (deprecating for one major cycle), > and then finally make the breaking change in N + 1? My understanding is things are not different than before, we just don’t do minors; wh

Re: [VOTE] Simplifying our release versioning process

+1 > On Apr 17, 2025, at 9:22 AM, Jon Haddad wrote: > > +1 > > On Thu, Apr 17, 2025 at 9:15 AM Josh McKenzie > wrote: >> +1 >> >> On Thu, Apr 17, 2025, at 11:58 AM, Josh McKenzie wrote: >>> [DISCUSS] thread: >>> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz

Re: Constraint's "not null" alignment with transactions and their simplification

One argument I have against using columns in the constraint is that we currently are not able to actually handle the CHECK spec in SQL. In SQL the CHECK expression is a valid search expression (eg. price > 42 AND tag = ‘foo’), and is limited to the current row. Where we differ in Apache Cassan

Re: Constraint's "not null" alignment with transactions and their simplification

7:47 AM, Jon Haddad wrote: >> >>  >> This looks like a really nice improvement to me. >> >> >> On Thu, Apr 10, 2025 at 7:27 AM Štefan Miklošovič > <mailto:smikloso...@apache.org>> wrote: >> Recently, David Capwell was commenting on constraint

Re: [DISCUSS] How we version our releases

> So here's what I'm thinking: a new release strategy that doesn't use .MINOR > of semver. Goals: So we avoid 6.1, 7.2, etc? Does this imply that each release is allowed to make breaking changes (assuming they followed the “correct” deprecation process)? My first instinct is to not like this,

Re: [DISCUSS] 5.1 should be 6.0

+1 to 6.0 Strong +1 to T-3, we should support 4.0/4.1 to 6.0 upgrades. > On Apr 10, 2025, at 2:18 PM, C. Scott Andreas wrote: > > +1 6.0 > > - Scott > > — > Mobile > >> On Apr 10, 2025, at 1:34 PM, Jeremy Hanna wrote: >> >> +1 for 6.0 for TCM/Accord changes, making it easier to make a case

Re: Meaningless emptiness and filtering

Been expanding the current AST Harry tests to include collections and UDTs and been finding even more fun with vs null… what Cassandra returns is a product of the schema and what you do with the table; and these types can act differently than other types. > On Feb 13, 2025, at 4:45 AM, Mick Se

Re: Inconsistent null handling between WHERE and IF clauses

support it, we have to treat NULL like we do in IF - even if > it’s not how we want it to work. > >> On 24 Mar 2025, at 23:45, David Capwell wrote: >> >> In fuzz testing I have found some differences between `WHERE` and `IF` >> clauses that want to get feedback f

Inconsistent null handling between WHERE and IF clauses

In fuzz testing I have found some differences between `WHERE` and `IF` clauses that want to get feedback from the broader community. If you try to query with a `null` we will reject it ``` @Test public void test() throws IOException { try (Cluster cluster = Cluster.build(1).start())

Re: Meaningless emptiness and filtering

Talking in slack I was linked to a Go Client issue (see https://the-asf.slack.com/archives/CK23JSY2K/p1742413507980149?thread_ts=1742409054.164389&cid=CK23JSY2K and https://the-asf.slack.com/archives/C05LPRVNZV1/p1741108083834769 ) gocql was sending empty bytes until recently… > On Mar 19, 20

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

Congrats! Very deserving! > On Mar 4, 2025, at 3:09 PM, Brandon Williams wrote: > > Congratulations Ekaterina! > > Kind Regards, > Brandon > > On Tue, Mar 4, 2025 at 2:25 PM Paulo Motta wrote: >> >> Aloha, >> >> The Project Management Committee (PMC) for Apache Cassandra is delighted to

Re: Meaningless emptiness and filtering

icit and - as David says - >>> inconsistent. It would be nice to move away from this as the default for a >>> variety of reasons, but also nice to make the behaviour well defined for >>> those use cases we think we’re supporting. >>> >>> On 11 Feb 2025, at 21:16

Re: Meaningless emptiness and filtering

pport, that would preferably NOT match EMPTY >> values for the types where empty means something, like strings. For >> everything else, EMPTY could be equivalent to null and match IS NULL. >> >> The only real way to make SAI compatible with the current behavior is to add >>

Meaningless emptiness and filtering

Bringing this discussion to dev@ rather than Slack as we try to figure out CASSANDRA-20313 and CASSANDRA-19461. In the type system, we have 2 different (but related) methods: AbstractType#allowsEmpty- if the user gives empty bytes (new byte[0]) will the type reject it Ab

Re: [VOTE] CEP-45: Mutation Tracking

+1 > On Feb 3, 2025, at 10:33 AM, Blake Eggleston wrote: > > Hi dev@, > > I’d like to start the voting for CEP-45: Mutation Tracking > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45:+Mutation+Tracking > Discussion: https://lists.apache.org/thread/0rstj4bzbb2596o5vw

Re: Capabilities

orage/dissemination mechanism, this feels like an > implementation detail. > > Ideally if this is well modularized, we can always plugin or replace it with > other backends (TCM/UDP/S3/morse code/whatever) once this is functional. > > On Wed, Jan 29, 2025 at 1:17 PM David Capw

Re: Capabilities

To be explicit about my concerns in the previous comments… TCM vs new table, I don’t care too much. I prefer TCM over new table, but its a preference My comment before were more about the UX of global configs. As long as we “could” (maybe per config, not every config likely needs this) allow

Re: [DISCUSS] 5.1 should be 6.0

I have not checked Jenkins, but we see this in another environment… For python upgrades have we actually audited the runtime to see that the time spent is doing real work? Josh and I have spent a ton of time trying to fix (and failing) an issue where the python driver blocks the test and we wai

Re: [DISCUSS] synchronisation of properties between Config.java and cassandra.yaml

So if you forget to update cassandra.yaml you fail the build? Makes sense to me. One additional thing I would like to see is the reverse… did you put something in yaml that isn’t in Config? This is a bug I have seen a few times…. Mostly because people don’t know the rules from SnakeYAML so ar

Re: Patrick McFadin joins the PMC

Congrats! > On Jan 22, 2025, at 10:06 AM, Jean-Armel Luce wrote: > > Congratulations, Patrick !! > > Le mer. 22 janv. 2025 à 18:55, Abe Ratnofsky > a écrit : >> Congrats Patrick! Well deserved. >> >>> On Jan 22, 2025, at 11:30, Ekaterina Dimitrova >>

Re: What branches should perf fixes be targeting

I think Paulo and I are in-sync on this. For me 4.x is mostly about stability right now and 5.x is more active development; so I have a higher bar for back ports to 4.x than I do to 5.x. There is also the question on “risk” which can be subjective from reviewer to reviewer. Some patches may be

Incorrectness in SELECT and purged Cells

During fuzz testing of Accord’s CQL integration, we identified an edge case that resulted in an IndexOutOfBoundsException. This issue was reported as CASSANDRA-20108 [1]. Initially, we believed this to be a type-related problem and did not draw attention to it. However, we ensured that the work

Re: [DISCUSS] Usage of "var" instead of types in the code

+1 to allow in tests > On Jan 9, 2025, at 10:58 AM, Caleb Rackliffe wrote: > > +1 to allowing in tests for now > > On Wed, Jan 8, 2025 at 12:51 PM Mick Semb Wever > wrote: >> >> Jumping in, I'm ok to allow it in tests for a trial period too. I would >> imagine in tes

Re: Capabilities

> Stefan, global configuration and capabilities do have some overlap but not > full overlap. For example, you may want to set globally that a cluster > enables feature X or control the threshold for a guardrail but you still need > to know if all nodes support feature X or have that guardrail, t

[DISCUSS] CASSANDRA-20163 DELETE partition IF static column condition is currently blocked

As part of the Accord work we have been extending the harry models to support even more of the CQL domain and added more test coverage for different features; in doing so it found the following query is currently blocked — delete partition if static column is in a given state — confirmed that th

Re: Supporting 2.2 -> 5.0 upgrades

assandra-sidecar), for example JMX Mbeans and other >>> interfaces. >>> >>> I think one way to do that would be to split cassandra-all into >>> cassandra-server and cassandra-common (anything used by both subprojects >>> and server), but not sur

Re: [DISCUSS] 5.1 should be 6.0

> My expectation is that in trunk SCM CASSANDRA_4 would change to SCM > CASSANDRA_5. Assuming you upgrade from 4.0 to 5.0, then you are running on CASSANDRA_4… how many people know that they are expected to do something about that (Sam documented the steps earlier)? What if you leave things al

Re: Supporting 2.2 -> 5.0 upgrades

From a disk format point of view the only thing I remember was the disk type bug with UDTs. Bringing that logic back was hard as the type system (in 5.0) tries to avoid allowing construction of invalid states, and we would need to weaken that in order to enable the migration. Assuming the user

Re: [DISCUSS] 5.1 should be 6.0

Given our version support… if we do make this change does this imply users must do the following to get to 6.0? 4.x upgrade to 5.0 5.0 upgrade to 6.0 So no 4.x to 6.0? Given that this is 5.1 atm we are expected to support 4.x to 5.1 upgrades, but switching to 6.0 that isn’t true based off our

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 > On Nov 5, 2024, at 1:34 PM, Mick Semb Wever wrote: > > > >> As per the CEP process documentation, this vote will be open for 72 hours >> (longer if needed). > > > > > +1

Re: [DISCUSS] Usage of "var" instead of types in the code

I am fine with allow in tests ban in src > On Oct 30, 2024, at 7:16 AM, Štefan Miklošovič wrote: > > https://issues.apache.org/jira/browse/CASSANDRA-20038 > > On Wed, Oct 30, 2024 at 2:40 PM Brandon Williams > wrote: >> Allow in tests, forbid elsewhere is my vote and s

Re: [DISCUSS] Usage of "var" instead of types in the code

I am one of the people using var, and this mostly comes from me doing “int” and having IntelliJ fix it (faster than typing out Future>>>)… so its a faster version for me… Personally I find that while I am writing the code I like var, but as I hone it I tend to remove it to improve readability.

Re: [Discuss] Repair inside C*

> Is there anyway it makes sense for this to be an external process rather than > a new thread pool inside the C* process? One thing to keep in mind is that larger clusters require you “smartly” split the ranges else you nuke your cluster… knowing how to split requires internal knowledge from t

Re: [VOTE] Release Apache Cassandra 5.0.2

+1 > On Oct 16, 2024, at 2:45 PM, Dinesh Joshi wrote: > > +1 > > On Wed, Oct 16, 2024 at 5:19 AM Mick Semb Wever > wrote: >> Proposing the test build of Cassandra 5.0.2 for release. >> >> sha1: f278f6774fc76465c182041e081982105c3e7dbb >> Git: https://github.com/apache/

Re: [DISCUSS] Donating easy-cass-stress to the project

> I think we should just accept easy-cass-stress as a subproject and go > from there. Replacing stress can be handled separately and still has > the large issue of reconciling the build systems that I raised in the > beginning of this thread, but can be figured out eventually. I strongly agree wi

Re: CEP-15: Accord status

7;t think we collectively should be worried about >>> disruption from this patch since: >>> Each commit (or the vast majority?) has already been reviewed by >= 1 other >>> committer >>> 7.3k deletions is a lot less than 42k >>> We now have fuzzin

Re: CEP-15: Accord status

gt; Most of this code is additive >> How would you recommend interested parties engage with reviewing this >> behemoth? Or perhaps subsections of it or key areas to familiarize >> themselves with the structure? >> >> On Fri, Sep 20, 2024, at 12:17 PM, David Capwell wrote: >&

CEP-15: Accord status

Recently, we rebased against the trunk branch, ensuring that the accord branch is now in sync with the latest trunk version. This presents an opportune moment for those interested to review the code. We have a pending pull request (https://github.com/apache/cassandra/pull/3552) that we do not i

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

> I think reserializing the payload into a new format is counter productive to > some of the performance goals of the binary logs? If you have to deserialize > and reserialize the message you are going to be throwing off a ton of extra > GC. That isn’t what happens in FQL =D. FQL creates a cus

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

> Do we need any of these things either? We have our own serialisation > framework and file readers and writers, and at least in the FQL case these > are the native serialisation format. > > At cursory glance it also looks to me like this would be a minimal refactor > from the current state. >

Re: [DISCUSS] CEP-39: Cost Based Optimizer

I am personally in favor of the idea and some of the finer details can be worked around I think. In https://issues.apache.org/jira/browse/CASSANDRA-19769 I added a AST for CQL for tests and improving our testing, which led me to file several tickets as it found bugs…. There is a large part of m

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

I personally don’t mind switching off Chronicle Queue. I have a transformer function to convert the FQL logs to Thrift (don’t judge) and use easy-cas to reply on a cluster… replying FQL from Chronicle Queue was far slower than Thrift and was hard to push the cluster as the client was the bottle

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

> if we are counting on users to read NEWS.txt, can we not count on them to > enable rejection if this is important to them? I think we can make the inverse statement… if accepting data loss is a tradeoff they want then disabling is there for them? So we could default for safety and let you op

Re: Welcome Jordan West and Stefan Miklosovic as Cassandra PMC members!

Congrats to the both of you! > On Aug 30, 2024, at 3:18 PM, Josh McKenzie wrote: > > Congratulations to both of you! > > On Fri, Aug 30, 2024, at 6:11 PM, Leo Toff wrote: >> Congratulations you guys! >> >> >> On Fri, Aug 30, 2024, 2:30 PM Ekaterina Dimitrova > >

Re: Welcome Doug Rohrer as Cassandra Committer

Congrats! > On Aug 23, 2024, at 1:38 PM, Bernardo Botella > wrote: > > Congratulations Doug! > >> On Aug 23, 2024, at 1:20 PM, Yifan Cai wrote: >> >> Congrats Doug! >> From: Jordan West >> Sent: Friday, August 23, 2024 1:19:04 PM >> To: dev@cassandra.apache.org >> Subject: Re: Welcome Doug

Re: CASSANDRA-19835 should block 5.0.0

Merged to 5.0.0 > On Aug 14, 2024, at 2:41 PM, Josh McKenzie wrote: > > This looks like a "merge it to 5.0.0 and re-rev rc" to me. > > On Wed, Aug 14, 2024, at 2:21 PM, David Capwell wrote: >> CASSANDRA-19835 fixes a very small bug but one that has big impact: i

CASSANDRA-19835 should block 5.0.0

CASSANDRA-19835 fixes a very small bug but one that has big impact: if you use trie Memtable and unslabbed_heap_buffers_logged Cassandra will crash on boot! If you use any other Memtable type and SAI you will break every SSTable write…. The patch is up now, its a 1 line code change just adding

Re: [DISCUSS] Removing support for deterministic table IDs

; <mailto:calebrackli...@gmail.com>> wrote: >>>>>> To clarify, my plan was to deprecate in Config/JMX and ignore it, not >>>>>> remove it entirely so it breaks existing YAMLs and JMX clients. >>>>>> >>>>>> This sh

Re: [DISCUSS] Removing support for deterministic table IDs

Users can provide ids and TCM can manage to make them safe, so agree we don’t really need the feature anymore. I am fine with deprecating the feature, but removing would be a breaking change for anyone that had that config in place, so not a fan of breaking the config interface. > On Jul 30, 2

Re: Welcome Joey Lynch as Cassandra PMC member

Congrats! > On Jul 24, 2024, at 10:41 AM, Jon Haddad wrote: > > Congrats Joey! > > On Wed, Jul 24, 2024 at 9:56 AM Francisco Guerrero > wrote: >> Congrats, Joey! >> >> On 2024/07/24 14:12:11 Benjamin Lerer wrote: >> > The PMC's members are pleased to announce that

Re: [DISCUSS] Replace airlift/airline library with Picocli

I am not for or against replacing… > I'm talkingabout CEP-38 [1], where I want to reuse the NodeTool commands and > execute them via CQL > 1. So the first requirement that airline doesn't fulfil is to allow us > to stay aside from all API-specific options of the commands and only > use them whe

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

brary as a project dependency getting any >> objections from the Community? Please, share your thoughts. >> >> There are a few other alternatives (commons-cli, airline2, jcommander) >> but they are not as well known and/or not as elegantly suited to our >> needs based on

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

> I don't personally think there is a strong need for a feature branch. If it > makes it easy for you, please go ahead with a feature branch. Agree, I don’t see the reason for a feature branch… feature branch just means the branch lives in apache domain rather than your own fork. You won’t be

Re: Cassandra PMC Chair Rotation, 2024 Edition

Congrats! > On Jun 20, 2024, at 9:10 AM, Melissa Logan wrote: > > Josh, thank you for your time as chair + congrats Dinesh! > > On Thu, Jun 20, 2024 at 9:08 AM Abe Ratnofsky > wrote: >> Congrats Dinesh! Thank you Josh! >> >>> On Jun 20, 2024, at 11:53 AM, Jeremiah Jordan

Re: [DISCUSS] Stream Pipelines on hot paths

I am cool for forbidding with a callout that tests are ok. I am cool with forbidding in tests as well, but thats just for consistency reasons than anything. > On May 31, 2024, at 8:12 AM, Brandon Williams wrote: > > > On Fri, May 31, 2024 at 9:35 AM Abe Ratnofsky > wrot

Re: [DISCUSS] Stream Pipelines on hot paths

agreement about edge cases, but if anyone in a discussion thinks something is a hot path then it should be treated as one IMO. On 30 May 2024, at 18:39, David Capwell wrote

Re: [DISCUSS] Stream Pipelines on hot paths

As a general statement I agree with you (same for String.format as well), but one thing to call out is that it can be hard to tell what is the hot path and what isn’t. When you are doing background work (like repair) its clear, but when touching something internal it can be hard to tell; this c

Re: [DISCUSS] The way we log

> I saw a lot of cases like this: > > if (logger.isTraceEnabled()) > logger.trace("a log message"); > > and sometimes just: > > logger.trace("a log message"); > > Why do we do it once like that and another time the other way? I remember years ago seeing perf numbers where the i

Re: [DISCUSS] Adding experimental vtables and rules around them

drail. Just a thought. I do not see yet how we could leverage it, just > saying how I perceive it. > > On Wed, May 29, 2024 at 9:02 PM David Capwell <mailto:dcapw...@apple.com>> wrote: >> We agreed a long time ago that all new features are disabled by default, but >>

[DISCUSS] Adding experimental vtables and rules around them

We agreed a long time ago that all new features are disabled by default, but I wanted to try to flesh out what we “should” do with something that might still be experimental and subject to breaking changes; I would prefer we keep this thread specific to vtables as the UX is different for differe

Re: [DISCUSS] Gossip Protocol Change

s that had serious impact (from >> data loss to loss of ability to safely replace nodes in the cluster). >> >> I am happy to contribute some time to this if lack of folks is the issue. >> >> Jordan >> >> On Mon, May 13, 2024 at 17:05 David Capwell >

Re: [DISCUSS] ccm as a subproject

Yes please! > On May 15, 2024, at 2:23 PM, Bret McGuire wrote: > >Very much agreed Paulo; I was musing on the idea of adding Docker support > to ccm recently as well. We'd want to preserve the current ability to work > with releases (and Github branches) but I very much like the idea of a

Re: [DISCUSS] Adding support for BETWEEN operator

; On 14/05/2024 16:59, Benjamin Lerer wrote: >>> It should be like range tombstones ... in much worse ;-). A tombstone is a >>> simple marker (deleted). An update can be far more complex. >>> >>> Le mar. 14 mai 2024 à 15:52, Jon Haddad a écrit : >>

Re: [DISCUSS] Adding support for BETWEEN operator

I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this work. > On May 13, 2024, at 7:40 AM, Patrick McFadin wrote: > > This is a great feature addition to CQL! I get asked about it from time to > time but then people figure out a workaround. It will be great to just have > it av

Re: [DISCUSS] Gossip Protocol Change

So, I created https://issues.apache.org/jira/browse/CASSANDRA-18917 which lets you do deterministic gossip simulation testing cross large clusters within seconds… I stopped this work as it conflicted with TCM (they were trying to merge that week) and it hit issues where some nodes never converge

Re: [DISCUSS] Donating easy-cass-stress to the project

> So: besides Jon, who in the community expects/desires to maintain this going > forward? I have been maintaining a fork for years, so don’t mind helping maintain this project. > On Apr 28, 2024, at 4:08 AM, Mick Semb Wever wrote: > >> A separate subproject like dtest and the Java driver wou

Re: [DISCUSS] Fixing coverage reports for jvm-dtest-upgrade

ClassLoader.html#getName-- > >> On Mar 18, 2024, at 3:48 PM, David Capwell wrote: >> >> Are there any side effects to naming ClassLoaders? How do we do this? >> >> I am +1 to the idea but don’t know enough to know what negatives could >> happen. >>

Re: [DISCUSS] Fixing coverage reports for jvm-dtest-upgrade

Are there any side effects to naming ClassLoaders? How do we do this? I am +1 to the idea but don’t know enough to know what negatives could happen. > On Mar 17, 2024, at 7:25 AM, Josh McKenzie wrote: > > +1 from me > >> If classloaders are appropriately named in the current versions of >> C

Re: [DISCUSSION] Replace the Config class instance with the tree-based framework

Just went over the doc and I don’t see a real argument for why we want to switch “frameworks”… I think this should be fleshed out more; what is it we are actually solving for? Also, I “think” its trying to propose we switch from a mostly flat yaml to a nested structure… I kinda feel this should

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

f4cac94ed80ed72c8789c0818e11d0 >>>>> >>>>> Was there something else in 3.29.0 that actually necessitated the move to >>>>> a floor of Python 3.8? Do we generally change runtime requirements in >>>>> minor releases for the driver? >>>

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

generally change runtime requirements in minor >>> releases for the driver? >>> >>> On Mon, Mar 11, 2024 at 12:12 PM Brandon Williams >> <mailto:dri...@gmail.com>> wrote: >>> Given that 3.6 has been EOL for 2+ years[1], I don't think it makes

[DISCUSS] Cassandra 5.0 support for RHEL 7

Originally we had planned to support RHEL 7 but in testing 5.0 we found out that cqlsh no longer works on RHEL 7[1]. This was changed in CASSANDRA-19245 which upgraded python-driver from 3.28.0 to 3.29.0. For some reason this minor version upgrade also dropped support for python 3.6 which is th

[DISCUSS] What SHOULD we do when we index an inet type that is ipv4?

So, was reviewing SAI and found we convert ipv4 to ipv6 (which is valid for the type) and made me wonder what the behavior would be if client mixed ipv4 with ipv4 encoded as ipv6… this caused me to find a different behavior in SAI to the rest of C*… where I feel C* is doing the wrong thing… Let

Re: Welcome Brad Schoening as Cassandra Committer

Congrats! > On Feb 26, 2024, at 2:14 AM, Mick Semb Wever wrote: > > Big Congrats Brad! > > On Wed, 21 Feb 2024 at 21:47, Josh McKenzie > wrote: >> The Apache Cassandra PMC is pleased to announce that Brad Schoening has >> accepted >> the invitation to become a co

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

I’m +1 once the tests are passing ands +0 while they are failingSent from my iPhoneOn Feb 16, 2024, at 6:08 AM, Paulo Motta wrote:Thanks for clarifying Branimir! I'm +1 on proceeding as proposed and I think this change will make it easier to gain confidence to update configurations.Interesting di

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

This thread got large quick, yay! >> is there a reason all guardrails and reliability (aka repair retries) >> configs are off by default? They are off by default in the normal config >> for backwards compatibility reasons, but if we are defining a config saying >> what we recommend, we should

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

> so can cause repairs to deadlock forever Small correction, I finished fixing the tests in CASSANDRA-19042 and we don’t deadlock, we timeout and fail repair if any of those messages are dropped. > On Feb 13, 2024, at 11:04 AM, David Capwell wrote: > >> and to point potential

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

> and to point potential users that are evaluating the technology to an > optimized set of defaults Left this comment in the GH… is there a reason all guardrails and reliability (aka repair retries) configs are off by default? They are off by default in the normal config for backwards compatib

Re: Welcome Maxim Muzafarov as Cassandra Committer

Congrats! > On Jan 8, 2024, at 10:53 AM, Jacek Lewandowski > wrote: > > Congratulations Maxim, well deserved, it's a pleasure to work with you! > > - - -- --- - - > Jacek Lewandowski > > > pon., 8 sty 2024 o 19:35 Lorina Poland > napisał(

Re: [DISCUSS] CEP-39: Cost Based Optimizer

imary indexes. >>>> In general, there are plenty of use cases that prefer determinism. So I >>>> agree that there should at least be a CBO implementation that makes the >>>> same decisions as the status quo, deterministically. >>>> >>>> I d

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

> A brief perusal shows jqwik as integrated with JUnit 5 taking a fairly > interesting annotation-based approach to property testing. Curious if you've > looked into or used that at all David (Capwell)? (link for the lazy: > https://jqwik.net/docs/current/user-guide.html#

Re: Moving Semver4j from test to main dependencies

+1 > On Dec 15, 2023, at 7:35 PM, Mick Semb Wever wrote: > > > >> I'd like to add Semver4j to the production dependencies. It is currently on >> the test classpath. The library is pretty lightweight, licensed with MIT and >> has no transitive dependencies. >> >> We need to represent the ker

Re: [DISCUSS] CEP-39: Cost Based Optimizer

Overall LGTM. > On Dec 12, 2023, at 5:29 AM, Benjamin Lerer wrote: > > Hi everybody, > > I would like to open the discussion on the introduction of a cost based > optimizer to allow Cassandra to pick the best execution plan based on the > data distribution.Therefore, improving the overall q

Re: Welcome Mike Adamson as Cassandra committer

Congrats! > On Dec 8, 2023, at 11:00 AM, Lorina Poland wrote: > > Congratulations, Mike!

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

+1 from me > On Nov 28, 2023, at 12:55 PM, Doug Rohrer wrote: > > +1 (nb, but not a vote, so ¯\_(ツ)_/¯ ) - would be lovely to not have to deal > with this individually for each project in which we use the in-jvm dtest > framework. As Francisco noted, we’re using this in the sidecar and Analyti

Re: [DISCUSS] Harry in-tree

+1 to in-tree > On Nov 27, 2023, at 9:17 AM, Benjamin Lerer wrote: > > +1 > > Le lun. 27 nov. 2023 à 18:01, Brandon Williams > a écrit : >> I am +1 on including Harry in-tree. >> >> Kind Regards, >> Brandon >> >> On Fri, Nov 24, 2023 at 9:44 AM Alex Petrov >

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

IR patch is up for review https://issues.apache.org/jira/browse/CASSANDRA-18962 > On Oct 24, 2023, at 3:15 PM, David Capwell wrote: > > I sat down to add IR messages to the mix… given how positive the feedback was > for other repair messages I assume people are still ok with this

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

retry logic > On Sep 26, 2023, at 12:08 PM, David Capwell wrote: > > Thanks all for the feedback! The patch has 2 +1s on trunk and back ported to > 5.0, making sure it’s stable now; I plan to merge early this week. > >> On Sep 21, 2023, at 2:07 PM, Ekaterina Dimitrova >

Re: CASSANDRA-18775 (Cassandra supported OSs)

+1 to drop the whole lib… > On Oct 20, 2023, at 7:55 AM, Jeremiah Jordan > wrote: > > Agreed. -1 on selectively removing any of the libs. But +1 for removing the > whole thing if it is no longer used. > > -Jeremiah > > On Oct 20, 2023 at 9:28:55 AM, Mick Semb Wever

Re: [DISCUSS] Gossip shutdown may corrupt peers making it so the cluster never converges, and a small protocol change to fix

PM, David Capwell wrote: > >> Won't the replacement have a newer generation? > > The replacement is a different instance. I performs a shadow round with its > seeds and if they are impacted by this issue then they are missing tokens, so > we fail the host replacement

Re: [DISCUSS] Gossip shutdown may corrupt peers making it so the cluster never converges, and a small protocol change to fix

randon Williams wrote: > > On Fri, Oct 6, 2023 at 5:50 PM David Capwell wrote: >> Lets say you now need to host replace node1 > > Won't the replacement have a newer generation? > >> avoid peers mutating endpoint states they don’t own > > This sounds reasonable to

[DISCUSS] Gossip shutdown may corrupt peers making it so the cluster never converges, and a small protocol change to fix

Just filed https://issues.apache.org/jira/browse/CASSANDRA-18913 (Gossip NPE due to shutdown event corrupting empty statuses) which is where I saw this issue.. When we do gossip shutdown we send a message GOSSIP_SHUTDOWN which then gets handled by this method org.apache.cassandra.gms.Gossiper#m

Re: [VOTE] Accept java-driver

+1 > On Oct 3, 2023, at 8:32 AM, Chris Lohfink wrote: > > +1 > > On Tue, Oct 3, 2023 at 10:30 AM Jeff Jirsa > wrote: >> +1 >> >> >> On Mon, Oct 2, 2023 at 9:53 PM Mick Semb Wever > > wrote: >>> The donation of the java-driver is ready for its

Re: multiple ParameterizedClass objects?

It would help me if you could give examples of what you want the yaml to look like and why it requires ParameterizedClass. I try to avoid that class as much as possible when doing configs and newer configs are finding different ways to solve the same problems... > On Oct 3, 2023, at 12:10 AM,

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

;> I think it could be argued that not retrying messages is a bug, I am >>>> +1 on including this in 5.0. >>>> >>>> Kind Regards, >>>> Brandon >>>> >>>> On Tue, Sep 19, 2023 at 1:16 PM David Capwell >>> <mailto:dc

Re: [DISCUSS] Vector type and empty value

nse: strings and blobs. All else >> should not allow this except for backward compatibility reasons. So, not for >> new types. >> >>>> On 20 Sep 2023, at 00:08, David Capwell wrote: >>>> >>>> When does empty mean null? >>> >>&

Re: [DISCUSS] Vector type and empty value

Days. It’s a distinct concern from columns being nullable or not. > > There are a couple types where this makes sense: strings and blobs. All else > should not allow this except for backward compatibility reasons. So, not for > new types. > >> On 20 Sep 2023, at 00:08, David Ca

  1   2   3   4   >