Re: [VOTE] Release Apache Cassandra 3.11.12

[C. Scott Andreas]

Hi Dorian,I see that the following download URLs appear to work fine for me and result in the 
tarballs being downloaded as expected.– 
https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/apache-cassandra-3.11.12-src.tar.gz– 
https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/apache-cassandra-3.11.12-bin.tar.gzAs 
Alex mentioned, to help the community debug and ensure a high quality release - in a JIRA ticket, 
could you please share specific steps to reproduce the issues you're encountering as well as any 
error messages you receive?We would like to resolve these concerns as quickly as 
possible.Thanks,– ScottOn Feb 7, 2022, at 1:11 PM, Dorian ROSSE  
wrote:-1 I don't success to download it I fall on index.htmlDe : Mick Semb Wever 
 Envoyé : lundi 7 février 2022 15:14 À : dev 
 Objet : [VOTE] Release Apache Cassandra 3.11.12  Proposing the 
test build of Cassandra 3.11.12 for release.  sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faaGit: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative 
Maven Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/
  The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available 
here: https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/  The vote will be open for 72 
hours (longer if needed). Everyone who has tested the build is invited to vote. Votes by PMC 
members are considered binding. A vote passes if there are at least three binding +1s and no 
-1's.  [1]: CHANGES.txt:  
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
 [2]: NEWS.txt:  
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative

Re: [VOTE] Release Apache Cassandra 3.11.12

[Brandon Williams]

+1. Smoke tested debs and rpms, unit tests passed.

On Mon, Feb 7, 2022 at 8:15 AM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 3.11.12 for release.
>
> sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa
>
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative
>
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative

Re: [VOTE] Release Apache Cassandra 3.0.26

[Brandon Williams]

+1. Smoke tested debs and rpms, unit tests passed.


On Mon, Feb 7, 2022 at 8:15 AM Mick Semb Wever  wrote:
>
> Proposing the test build of Cassandra 3.0.26 for release.
>
> sha1: b18adcba1a808cf77576905dc2ceccd7783bdb18
>
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentative
>
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.26/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.26-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative
>

RE: [VOTE] Release Apache Cassandra 3.11.12

[Dorian ROSSE]

-1 I don't success to download it I fall on index.html

De : Mick Semb Wever 
Envoyé : lundi 7 février 2022 15:14
À : dev 
Objet : [VOTE] Release Apache Cassandra 3.11.12

Proposing the test build of Cassandra 3.11.12 for release.

sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa

Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative

RE: [VOTE] Release Apache Cassandra 4.0.2

[Dorian ROSSE]

cqlsh doesn't success to run, when i launch cqlsh.py the error is the firewall 
doesn't allow cqlsh

De : Alex Petrov 
Envoyé : lundi 7 février 2022 21:51
À : dev@cassandra.apache.org 
Objet : Re: [VOTE] Release Apache Cassandra 4.0.2

Could you elaborate what exactly went wrong so we could asses and potentially 
fix the build?

On Mon, Feb 7, 2022, at 9:50 PM, Dorian ROSSE wrote:
-1 I don't success to install apache cassandra



De : Mick Semb Wever 
Envoyé : lundi 7 février 2022 15:14
À : dev 
Objet : [VOTE] Release Apache Cassandra 4.0.2

Proposing the test build of Cassandra 4.0.2 for release.

sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5

Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

RE: [VOTE] Release Apache Cassandra 3.0.26

[Dorian ROSSE]

-1 I fall on index.html downloading

De : Mick Semb Wever 
Envoyé : lundi 7 février 2022 15:14
À : dev 
Objet : [VOTE] Release Apache Cassandra 3.0.26

Proposing the test build of Cassandra 3.0.26 for release.

sha1: b18adcba1a808cf77576905dc2ceccd7783bdb18

Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentative

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/3.0.26/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.26-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative

RE: [VOTE] Release Apache Cassandra 3.11.12

[Dorian ROSSE]

-1 I don't success to download it I donf always on index.html downloading

De : Mick Semb Wever 
Envoyé : lundi 7 février 2022 15:14
À : dev 
Objet : [VOTE] Release Apache Cassandra 3.11.12

Proposing the test build of Cassandra 3.11.12 for release.

sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa

Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative

Re: [VOTE] Release Apache Cassandra 4.0.2

[Alex Petrov]

Could you elaborate what exactly went wrong so we could asses and potentially 
fix the build?

On Mon, Feb 7, 2022, at 9:50 PM, Dorian ROSSE wrote:
> -1 I don't success to install apache cassandra
> 
> 
> *De :* Mick Semb Wever 
> *Envoyé :* lundi 7 février 2022 15:14
> *À :* dev 
> *Objet :* [VOTE] Release Apache Cassandra 4.0.2 
>  
> Proposing the test build of Cassandra 4.0.2 for release.
> 
> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
> 
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

RE: [VOTE] Release Apache Cassandra 4.0.2

[Dorian ROSSE]

-1 I don't success to install apache cassandra

De : Mick Semb Wever 
Envoyé : lundi 7 février 2022 15:14
À : dev 
Objet : [VOTE] Release Apache Cassandra 4.0.2

Proposing the test build of Cassandra 4.0.2 for release.

sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5

Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

Re: [DISCUSS] CEP-19: Trie memtable implementation

[C. Scott Andreas]

Branimir, thank you for sharing these results. 

The numbers are exciting - particularly the UCS test in which compaction keeps 
up, and your note mentioning 30% larger L0 flushes due to the more compact 
memory representation.

Great work.

— Scott

> On Feb 7, 2022, at 8:39 AM, Branimir Lambov  wrote:
> 
> 
> Added some performance results to the ticket: 
> https://issues.apache.org/jira/browse/CASSANDRA-17240
> 
> Regards,
> Branimir
> 
>> On Sat, Feb 5, 2022 at 10:59 PM Dinesh Joshi  wrote:
>> This is excellent. Thanks for opening up this CEP. It would be great to get 
>> some stats around GC allocation rate / memory pressure, read & write 
>> latencies, etc. compared to existing implementation.
>> 
>> Dinesh
>> 
>>> On Jan 18, 2022, at 2:13 AM, Branimir Lambov  wrote:
>>> 
>>> The memtable pluggability API (CEP-11) is per-table to enable memtable 
>>> selection that suits specific workflows. It also makes full sense to permit 
>>> per-node configuration, both to be able to modify the configuration to suit 
>>> heterogeneous deployments better, as well as to test changes for 
>>> improvements such as this one.
>>> Recognizing this, the patch comes with a modification to the API that 
>>> defines memtable templates in cassandra.yaml (i.e. per node) and allows the 
>>> schema to select a template (in addition to being able to specify the full 
>>> memtable configuration). One could use this e.g. by adding:
>>> memtable_templates:
>>> trie:
>>> class: TrieMemtable
>>> shards: 16
>>> skiplist:
>>> class: SkipListMemtable
>>> memtable:
>>> template: skiplist
>>> (which defines two templates and specifies the default memtable 
>>> implementation to use) to cassandra.yaml and specifying  WITH memtable = 
>>> {'template' : 'trie'} in the table schema.
>>> 
>>> I intend to commit this modification with the memtable API 
>>> (CASSANDRA-17034/CEP-11).
>>> 
>>> Performance comparisons will be published soon.
>>> 
>>> Regards,
>>> Branimir
>>> 
 On Fri, Jan 14, 2022 at 4:15 PM Jeff Jirsa  wrote:
 Sounds like a great addition
 
 Can you share some of the details around gc and latency improvements 
 you’ve observed with the list? 
 
 Any specific reason the confirmation is through schema vs yaml? Presumably 
 it’s so a user can test per table, but this changes every host in a 
 cluster, so the impact of a bug/regression is much higher. 
 
 
>> On Jan 10, 2022, at 1:30 AM, Branimir Lambov  wrote:
>> 
> 
> We would like to contribute our TrieMemtable to Cassandra. 
> 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
> 
> This is a new memtable solution aimed to replace the legacy 
> implementation, developed with the following objectives:
> - lowering the on-heap complexity and the ability to store memtable 
> indexing structures off-heap,
> - leveraging byte order and a trie structure to lower the memory 
> footprint and improve mutation and lookup performance.
> 
> The new memtable relies on CASSANDRA-6936 to translate to and from 
> byte-ordered representations of types, and CASSANDRA-17034 / CEP-11 to 
> plug into Cassandra. The memtable is built on multiple shards of custom 
> in-memory single-writer multiple-reader tries, whose implementation uses 
> a combination of state-of-the-art and novel features for greater 
> efficiency.
> 
> The CEP's JIRA ticket 
> (https://issues.apache.org/jira/browse/CASSANDRA-17240) contains the 
> initial version of the implementation. In its current form it achieves 
> much better garbage collection latency, significantly bigger data sizes 
> between flushes for the same memory allocation, as well as drastically 
> increased write throughput, and we expect the memory and garbage 
> collection improvements to go much further with upcoming improvements to 
> the solution.
> 
> I am interested in hearing your thoughts on the proposal.
> 
> Regards,
> Branimir
> 
>> 

Re: [VOTE] Release Apache Cassandra 3.0.26

[C. Scott Andreas]

+1nbOn Feb 7, 2022, at 6:14 AM, Mick Semb Wever  
wrote:Proposing the test build of Cassandra 3.0.26 for release.sha1: 
b18adcba1a808cf77576905dc2ceccd7783bdb18Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentativeMaven
 Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/The
 Source and Build Artifacts, and the Debian and RPM packages and repositories, are 
available here: https://dist.apache.org/repos/dist/dev/cassandra/3.0.26/The vote will 
be open for 72 hours (longer if needed). Everyone who has tested the build is invited 
to vote. Votes by PMC members are considered binding. A vote passes if there are at 
least three binding +1s and no -1's.[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.26-tentative[2]:
 NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative

Re: [VOTE] Release Apache Cassandra 4.0.2

[C. Scott Andreas]

+1nbOn Feb 7, 2022, at 6:15 AM, Mick Semb Wever  
wrote:Proposing the test build of Cassandra 4.0.2 for release.sha1: 
25012d2fec1984cc9c1a352f214eb912ca4f10f5Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentativeMaven
 Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/The
 Source and Build Artifacts, and the Debian and RPM packages and repositories, are 
available here: https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/The vote will 
be open for 72 hours (longer if needed). Everyone who has tested the build is invited 
to vote. Votes by PMC members are considered binding. A vote passes if there are at 
least three binding +1s and no -1's.[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative[2]:
 NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

Cassandra project biweekly status update 2021-02-07

[Joshua McKenzie]

This is the Special "We need to talk" edition. :)

Something interesting changed in the past two weeks - we had our first
couple of rotations of a Build Lead (
https://cwiki.apache.org/confluence/display/CASSANDRA/Build+Lead).

And why do we need to talk? Well, Brandon and I created a lot of test
failure tickets. And by "A lot", I mean 42:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20reporter%20IN%20(jmckenzie%2C%20brandon.williams)%20AND%20created%20%3E%20-14d

If you take a look at what's going on in Butler, you'll see that for 3.0,
3.11, and 4.0 our test failure rates are either increasing or holding
steady with a current total of 82 test failures between these three
versions. If we assume that all of those failures are duplicates (generous
of us), that still leaves us with a consistent 27 test failures on each
branch. This number of test failures effectively leaves us holding our
noses and merging with current non-test fixing changes, slowly worsening an
already messy situation.

For what it's worth, if we include trunk things get differently murky. On
the plus side we only have 16 failures there today, whereas on the downside
that's "for today" and test runs on trunk can't seem to make up their mind,
ranging from a low of 10 failures to highs of 49 and 67.

So what can we do about this? Well, if we had only 15 active contributors
(undershooting to illustrate the point) and each of them took 2 test
failures each week for the next 2 weeks, that'd be enough to drive down
most if not all of the failures across 3.0, 3.11, and 4.0. It's important
that we keep a clean test board because when things like security CVE's or
data loss defects come along, we need to be able to cut a quick hotfix
release without worrying about whether we're introducing new regressions
into critical production systems running GA release lines. It's hard to
overstate how critical this is to us as a project.

So in short, the outstanding question we as a project haven't tackled yet
is: how are we going to resource fixing these tests now that we have them
wired up in butler and JIRA and have them identified?


[New contributors]
Did you know fixing failing tests is a great way to get to know the
Cassandra codebase? :) This is actually in all seriousness, not in jest due
to what's above. Tests can be tricky, interesting, and quite educational if
you're opening up an area of the codebase you haven't worked on before, and
you can always hit up @cassandra_mentors in the #cassandra-dev channel on
the ASF slack server here: https://the-asf.slack.com

For convenience, here's a link to a kanban board of the currently
identified failing test JIRA's that haven't been assigned yet:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=496=2252
64 of them! A veritable cornucopia of interesting work.

If test failures aren't your bag, we have 14 tickets unassigned that are
solid starter tickets on the 4.0.x line, and 14 on the 4.x line you could
tackle:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484=2162=2160


[Dev mailing list conversations]
https://lists.apache.org/list?dev@cassandra.apache.org:lte=2w:

The last two weeks have seen momentum pick up a bit on the dev list. Some
highlights to get engaged with:

The trie-memtable thread got some very interesting updating today; Branimir
attached some performance numbers from the implementation compared to our
current skip list:
https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty

Ekaterina landed CASSANDRA-15234 to standardise our config and JVM
parameters. This is a significant achievement and a ton of work to get
across the line - congrats Ekaterina! Email thread here:
https://lists.apache.org/thread/qf4ctv1067hz5j0pm6wc75rr44kospk4
One thing to be aware of is around the follow-up Ekaterina sent to the list
about our test suite misbehaving:
https://issues.apache.org/jira/browse/CASSANDRA-17351.

The ever lurking zombie conversation about ant vs. maven vs. gradle has
risen from the dead again:
https://lists.apache.org/thread/jksl415lvfmrnh7z7xvy41v3d25twc5w. We've
never really put a bow on this in the past and traditionally the
conversation fizzles out; the outstanding request from several of us today
is a clear enumeration of pros vs. cons, value vs. cost for each of the
different build systems so we can either make a decision as a project on
this or agree to put it to rest and not revisit it for a set amount of
time. To whomever decides to take up that torch, know that there are hordes
of people ready to share their opinions about their favored build system
with you (not sure if this is encouraging or not =/).

SharanF opened up an interesting and much-needed (editorializing alert)
thread about non-Java-code contributing committers on the project here:
https://lists.apache.org/thread/mlqqxcmyz60fd8mzn66nslp5nxlnryld. The
overloading of the term to mean both "someone with commit bit who commits
code" and "someone who is 

Re: [DISCUSS] CEP-19: Trie memtable implementation

[Branimir Lambov]

Added some performance results to the ticket:
https://issues.apache.org/jira/browse/CASSANDRA-17240

Regards,
Branimir

On Sat, Feb 5, 2022 at 10:59 PM Dinesh Joshi  wrote:

> This is excellent. Thanks for opening up this CEP. It would be great to
> get some stats around GC allocation rate / memory pressure, read & write
> latencies, etc. compared to existing implementation.
>
> Dinesh
>
> On Jan 18, 2022, at 2:13 AM, Branimir Lambov  wrote:
>
> The memtable pluggability API (CEP-11) is per-table to enable memtable
> selection that suits specific workflows. It also makes full sense to permit
> per-node configuration, both to be able to modify the configuration to suit
> heterogeneous deployments better, as well as to test changes for
> improvements such as this one.
> Recognizing this, the patch comes with a modification to the API
> 
> that defines memtable templates in cassandra.yaml (i.e. per node) and
> allows the schema to select a template (in addition to being able to
> specify the full memtable configuration). One could use this e.g. by adding:
>
> memtable_templates:
> trie:
> class: TrieMemtable
> shards: 16
> skiplist:
> class: SkipListMemtable
> memtable:
> template: skiplist
>
> (which defines two templates and specifies the default memtable
> implementation to use) to cassandra.yaml and specifying  WITH memtable =
> {'template' : 'trie'} in the table schema.
>
> I intend to commit this modification with the memtable API
> (CASSANDRA-17034/CEP-11).
>
> Performance comparisons will be published soon.
>
> Regards,
> Branimir
>
> On Fri, Jan 14, 2022 at 4:15 PM Jeff Jirsa  wrote:
>
>> Sounds like a great addition
>>
>> Can you share some of the details around gc and latency improvements
>> you’ve observed with the list?
>>
>> Any specific reason the confirmation is through schema vs yaml?
>> Presumably it’s so a user can test per table, but this changes every host
>> in a cluster, so the impact of a bug/regression is much higher.
>>
>>
>> On Jan 10, 2022, at 1:30 AM, Branimir Lambov  wrote:
>>
>> 
>> We would like to contribute our TrieMemtable to Cassandra.
>>
>>
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
>>
>> This is a new memtable solution aimed to replace the legacy
>> implementation, developed with the following objectives:
>> - lowering the on-heap complexity and the ability to store memtable
>> indexing structures off-heap,
>> - leveraging byte order and a trie structure to lower the memory
>> footprint and improve mutation and lookup performance.
>>
>> The new memtable relies on CASSANDRA-6936 to translate to and from
>> byte-ordered representations of types, and CASSANDRA-17034 / CEP-11 to plug
>> into Cassandra. The memtable is built on multiple shards of custom
>> in-memory single-writer multiple-reader tries, whose implementation uses a
>> combination of state-of-the-art and novel features for greater efficiency.
>>
>> The CEP's JIRA ticket (
>> https://issues.apache.org/jira/browse/CASSANDRA-17240) contains the
>> initial version of the implementation. In its current form it achieves much
>> better garbage collection latency, significantly bigger data sizes between
>> flushes for the same memory allocation, as well as drastically increased
>> write throughput, and we expect the memory and garbage collection
>> improvements to go much further with upcoming improvements to the solution.
>>
>> I am interested in hearing your thoughts on the proposal.
>>
>> Regards,
>> Branimir
>>
>>
>

[VOTE] release cassandra-harry 0.0.1

[Alex Petrov]

Proposing the test build of cassandra-harry 0.0.1 for release, to start using 
it in Cassandra tree.

Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.1

Candidate SHA:
https://github.com/apache/cassandra-harry/commit/40fb37ec8a4f08dc6a258a50cbdeab92e2894266
tagged with 0.0.1

Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1257/org/apache/cassandra/

Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB

This is a first release of harry-core, but you can read more about its 
integration with Cassandra in CASSANDRA-16262:

The vote will be open for 24 hours. Everyone who has tested the build
is invited to vote. Votes by PMC members are considered binding. A
vote passes if there are at least three binding +1s.

[VOTE] Release Apache Cassandra 4.0.2

[Mick Semb Wever]

Proposing the test build of Cassandra 4.0.2 for release.

sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5

Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/

The vote will be open for 72 hours (longer if needed). Everyone who has
tested the build is invited to vote. Votes by PMC members are considered
binding. A vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

[VOTE] Release Apache Cassandra 3.11.12

[Mick Semb Wever]

Proposing the test build of Cassandra 3.11.12 for release.

sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa

Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/

The vote will be open for 72 hours (longer if needed). Everyone who has
tested the build is invited to vote. Votes by PMC members are considered
binding. A vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative

[VOTE] Release Apache Cassandra 3.0.26

[Mick Semb Wever]

Proposing the test build of Cassandra 3.0.26 for release.

sha1: b18adcba1a808cf77576905dc2ceccd7783bdb18

Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentative

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/3.0.26/

The vote will be open for 72 hours (longer if needed). Everyone who has
tested the build is invited to vote. Votes by PMC members are considered
binding. A vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.26-tentative
[2]: NEWS.txt:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative

Re: [DISCUSS] CEP-7 Storage Attached Index

[bened...@apache.org]

I don’t have a strong opinion about CEP-7 taking a hard dependency on any new 
CQL CEP, particularly from a point of view of first landing in the codebase.


From: Henrik Ingo 
Date: Monday, 7 February 2022 at 12:03
To: dev@cassandra.apache.org 
Subject: Re: [DISCUSS] CEP-7 Storage Attached Index
Thanks Benjamin for reviewing and raising this.

While I don't speak for the CEP authors, just some thoughts from me:

On Mon, Feb 7, 2022 at 11:18 AM Benjamin Lerer 
mailto:ble...@apache.org>> wrote:
I would like to raise 2 points regarding the current CEP proposal:

1. There are mention of some target versions and of the removal of SASI

At this point, we have not agreed on any version numbers and I do not feel that 
removing SASI should be part of the proposal for now.
It seems to me that we should see first the adoption surrounding SAI before 
talking about deprecating other solutions.


This seems rather uncontroversial. I think the CEP template and previous CEPs 
invite  the discussion on whether the new feature will or may replace an 
existing feature. But at the same time that's of course out of scope for the 
work at hand. I have no opinion one way or the other myself.


2. OR queries

It is unclear to me if the proposal is about adding OR support only for SAI 
index or for other types of queries too.
In the past, we had the nasty habit for CQL to provide only partialially 
implemented features which resulted in a bad user experience.
Some examples are:
* LIKE restrictions which were introduced for the need of SASI and were not 
never supported for other type of queries
* IS NOT NULL restrictions for MATERIALIZED VIEWS that are not supported 
elsewhere
* != operator only supported for conditional inserts or updates
And there are unfortunately many more.

We are currenlty slowly trying to fix those issue and make CQL a more mature 
language. By consequence, I would like that we change our way of doing things. 
If we introduce support for OR it should also cover all the other type of 
queries and be fully tested.
I also believe that it is a feature that due to its complexity fully deserves 
its own CEP.


The current code that would be submitted for review after the CEP is adopted, 
contains OR support beyond just SAI indexes. An initial implementation first 
targeted only such queries where all columns in a WHERE clause using OR needed 
to be backed by an SAI index. This was since extended to also support ALLOW 
FILTERING mode as well as OR with clustering key columns. The current 
implementation is by no means perfect as a general purpose OR support, the 
focus all the time was on implementing OR support in SAI. I'll leave it to 
others to enumerate exactly the limitations of the current implementation.

Seeing that also Benedict supports your point of view, I would steer the 
conversation more into a project management perspective:
* How can we advance CEP-7 so that the bulk of the SAI code can still be added 
to Cassandra, so that  users can benefit from this new index type, albeit 
without OR?
* This is also an important question from the point of view that this is a 
large block of code that will inevitably diverged if it's not in trunk. Also, 
merging it to trunk will allow future enhancements, including the OR syntax 
btw, to happen against trunk (aka upstream first).
* Since OR support nevertheless is a feature of SAI, it needs to be at least 
unit tested, but ideally even would be exposed so that it is possible to test 
on the CQL level. Is there some mechanism such as experimental flags, which 
would allow the SAI-only OR support to be merged into trunk, while a separate 
CEP is focused on implementing "proper" general purpose OR support? I should 
note that there is no guarantee that the OR CEP would be implemented in time 
for the next release. So the answer to this point needs to be something that 
doesn't violate the desire for good user experience.

henrik

Re: [DISCUSS] CEP-7 Storage Attached Index

[J. D. Jordan]

Given this discussion +1 from me to move OR to its own CEP separate from the 
new index implementation.

> On Feb 7, 2022, at 6:51 AM, Benjamin Lerer  wrote:
> 
> 
>> This was since extended to also support ALLOW FILTERING mode as well as OR 
>> with clustering key columns.
> 
> If the code is able to support query using clustering columns  without the 
> need for filtering + filtering queries then it should be relatively easy to 
> have full support for CQL.
> We also need some proper test coverage and ideally some validation with Harry.
> 
>>   * Since OR support nevertheless is a feature of SAI, it needs to be at 
>> least unit tested, but ideally even would be exposed so that it is possible 
>> to test on the CQL level. Is there some mechanism such as experimental 
>> flags, which would allow the SAI-only OR support to be merged into trunk, 
>> while a separate CEP is focused on implementing "proper" general purpose OR 
>> support? I should note that there is no guarantee that the OR CEP would be 
>> implemented in time for the next release. So the answer to this point needs 
>> to be something that doesn't violate the desire for good user experience.
> 
> This is currently what we have with SASI. Currently SASI is behind an 
> experimental flag but nevertheless the LIKE restriction code has been 
> introduced as part of the code base and its use will result in an error 
> without a SASI index.
> SASI has been there for multiple years and we still do not support LIKE 
> restrictions for other use cases.
> I am against that approach because I do believe that it is what has led us 
> where we are today. We need to stop adding bits of CQL grammar to fulfill the 
> need of a given feature and start considering CQL as a whole.
> 
> I am in favor of moving forward with SAI without OR support until OR can be 
> properly added to CQL. 
> 
>  
>  
> 
>> Le lun. 7 févr. 2022 à 13:11, Henrik Ingo  a écrit 
>> :
>> Thanks Benjamin for reviewing and raising this.
>> 
>> While I don't speak for the CEP authors, just some thoughts from me:
>> 
>>> On Mon, Feb 7, 2022 at 11:18 AM Benjamin Lerer  wrote:
>> 
>>> I would like to raise 2 points regarding the current CEP proposal:
>>> 
>>> 1. There are mention of some target versions and of the removal of SASI 
>>> 
>>> At this point, we have not agreed on any version numbers and I do not feel 
>>> that removing SASI should be part of the proposal for now.
>>> It seems to me that we should see first the adoption surrounding SAI before 
>>> talking about deprecating other solutions.
>>> 
>> 
>> This seems rather uncontroversial. I think the CEP template and previous 
>> CEPs invite  the discussion on whether the new feature will or may replace 
>> an existing feature. But at the same time that's of course out of scope for 
>> the work at hand. I have no opinion one way or the other myself.
>> 
>>  
>>> 2. OR queries
>>> 
>>> It is unclear to me if the proposal is about adding OR support only for SAI 
>>> index or for other types of queries too.
>>> In the past, we had the nasty habit for CQL to provide only partialially 
>>> implemented features which resulted in a bad user experience.
>>> Some examples are:
>>> * LIKE restrictions which were introduced for the need of SASI and were not 
>>> never supported for other type of queries
>>> * IS NOT NULL restrictions for MATERIALIZED VIEWS that are not supported 
>>> elsewhere
>>> * != operator only supported for conditional inserts or updates
>>> And there are unfortunately many more.
>>> 
>>> We are currenlty slowly trying to fix those issue and make CQL a more 
>>> mature language. By consequence, I would like that we change our way of 
>>> doing things. If we introduce support for OR it should also cover all the 
>>> other type of queries and be fully tested.
>>> I also believe that it is a feature that due to its complexity fully 
>>> deserves its own CEP.
>>> 
>> 
>> The current code that would be submitted for review after the CEP is 
>> adopted, contains OR support beyond just SAI indexes. An initial 
>> implementation first targeted only such queries where all columns in a WHERE 
>> clause using OR needed to be backed by an SAI index. This was since extended 
>> to also support ALLOW FILTERING mode as well as OR with clustering key 
>> columns. The current implementation is by no means perfect as a general 
>> purpose OR support, the focus all the time was on implementing OR support in 
>> SAI. I'll leave it to others to enumerate exactly the limitations of the 
>> current implementation.
>> 
>> Seeing that also Benedict supports your point of view, I would steer the 
>> conversation more into a project management perspective:
>> * How can we advance CEP-7 so that the bulk of the SAI code can still be 
>> added to Cassandra, so that  users can benefit from this new index type, 
>> albeit without OR?
>> * This is also an important question from the point of view that this is a 
>> large block of code that will 

Re: [DISCUSS] CEP-7 Storage Attached Index

[Benjamin Lerer]

>
> This was since extended to also support ALLOW FILTERING mode as well as OR
> with clustering key columns.


If the code is able to support query using clustering columns  without the
need for filtering + filtering queries then it should be relatively easy to
have full support for CQL.
We also need some proper test coverage and ideally some validation with
Harry.

  * Since OR support nevertheless is a feature of SAI, it needs to be at
> least unit tested, but ideally even would be exposed so that it is possible
> to test on the CQL level. Is there some mechanism such as experimental
> flags, which would allow the SAI-only OR support to be merged into trunk,
> while a separate CEP is focused on implementing "proper" general purpose OR
> support? I should note that there is no guarantee that the OR CEP would be
> implemented in time for the next release. So the answer to this point needs
> to be something that doesn't violate the desire for good user experience.
>

This is currently what we have with SASI. Currently SASI is behind an
experimental flag but nevertheless the LIKE restriction code has been
introduced as part of the code base and its use will result in an error
without a SASI index.
SASI has been there for multiple years and we still do not support LIKE
restrictions for other use cases.
I am against that approach because I do believe that it is what has led us
where we are today. We need to stop adding bits of CQL grammar to fulfill
the need of a given feature and start considering CQL as a whole.

I am in favor of moving forward with SAI without OR support until OR can be
properly added to CQL.




Le lun. 7 févr. 2022 à 13:11, Henrik Ingo  a
écrit :

> Thanks Benjamin for reviewing and raising this.
>
> While I don't speak for the CEP authors, just some thoughts from me:
>
> On Mon, Feb 7, 2022 at 11:18 AM Benjamin Lerer  wrote:
>
>> I would like to raise 2 points regarding the current CEP proposal:
>>
>> 1. There are mention of some target versions and of the removal of SASI
>>
>> At this point, we have not agreed on any version numbers and I do not
>> feel that removing SASI should be part of the proposal for now.
>> It seems to me that we should see first the adoption surrounding SAI
>> before talking about deprecating other solutions.
>>
>>
> This seems rather uncontroversial. I think the CEP template and previous
> CEPs invite  the discussion on whether the new feature will or may replace
> an existing feature. But at the same time that's of course out of scope for
> the work at hand. I have no opinion one way or the other myself.
>
>
>
>> 2. OR queries
>>
>> It is unclear to me if the proposal is about adding OR support only for
>> SAI index or for other types of queries too.
>> In the past, we had the nasty habit for CQL to provide only partialially
>> implemented features which resulted in a bad user experience.
>> Some examples are:
>> * LIKE restrictions which were introduced for the need of SASI and were
>> not never supported for other type of queries
>> * IS NOT NULL restrictions for MATERIALIZED VIEWS that are not supported
>> elsewhere
>> * != operator only supported for conditional inserts or updates
>> And there are unfortunately many more.
>>
>> We are currenlty slowly trying to fix those issue and make CQL a more
>> mature language. By consequence, I would like that we change our way of
>> doing things. If we introduce support for OR it should also cover all the
>> other type of queries and be fully tested.
>> I also believe that it is a feature that due to its complexity fully
>> deserves its own CEP.
>>
>>
> The current code that would be submitted for review after the CEP is
> adopted, contains OR support beyond just SAI indexes. An initial
> implementation first targeted only such queries where all columns in a
> WHERE clause using OR needed to be backed by an SAI index. This was since
> extended to also support ALLOW FILTERING mode as well as OR with clustering
> key columns. The current implementation is by no means perfect as a general
> purpose OR support, the focus all the time was on implementing OR support
> in SAI. I'll leave it to others to enumerate exactly the limitations of the
> current implementation.
>
> Seeing that also Benedict supports your point of view, I would steer the
> conversation more into a project management perspective:
> * How can we advance CEP-7 so that the bulk of the SAI code can still be
> added to Cassandra, so that  users can benefit from this new index type,
> albeit without OR?
> * This is also an important question from the point of view that this is a
> large block of code that will inevitably diverged if it's not in trunk.
> Also, merging it to trunk will allow future enhancements, including the OR
> syntax btw, to happen against trunk (aka upstream first).
> * Since OR support nevertheless is a feature of SAI, it needs to be at
> least unit tested, but ideally even would be exposed so that it is possible
> to test on the CQL 

Re: [DISCUSS] CEP-7 Storage Attached Index

[Henrik Ingo]

Thanks Benjamin for reviewing and raising this.

While I don't speak for the CEP authors, just some thoughts from me:

On Mon, Feb 7, 2022 at 11:18 AM Benjamin Lerer  wrote:

> I would like to raise 2 points regarding the current CEP proposal:
>
> 1. There are mention of some target versions and of the removal of SASI
>
> At this point, we have not agreed on any version numbers and I do not feel
> that removing SASI should be part of the proposal for now.
> It seems to me that we should see first the adoption surrounding SAI
> before talking about deprecating other solutions.
>
>
This seems rather uncontroversial. I think the CEP template and previous
CEPs invite  the discussion on whether the new feature will or may replace
an existing feature. But at the same time that's of course out of scope for
the work at hand. I have no opinion one way or the other myself.



> 2. OR queries
>
> It is unclear to me if the proposal is about adding OR support only for
> SAI index or for other types of queries too.
> In the past, we had the nasty habit for CQL to provide only partialially
> implemented features which resulted in a bad user experience.
> Some examples are:
> * LIKE restrictions which were introduced for the need of SASI and were
> not never supported for other type of queries
> * IS NOT NULL restrictions for MATERIALIZED VIEWS that are not supported
> elsewhere
> * != operator only supported for conditional inserts or updates
> And there are unfortunately many more.
>
> We are currenlty slowly trying to fix those issue and make CQL a more
> mature language. By consequence, I would like that we change our way of
> doing things. If we introduce support for OR it should also cover all the
> other type of queries and be fully tested.
> I also believe that it is a feature that due to its complexity fully
> deserves its own CEP.
>
>
The current code that would be submitted for review after the CEP is
adopted, contains OR support beyond just SAI indexes. An initial
implementation first targeted only such queries where all columns in a
WHERE clause using OR needed to be backed by an SAI index. This was since
extended to also support ALLOW FILTERING mode as well as OR with clustering
key columns. The current implementation is by no means perfect as a general
purpose OR support, the focus all the time was on implementing OR support
in SAI. I'll leave it to others to enumerate exactly the limitations of the
current implementation.

Seeing that also Benedict supports your point of view, I would steer the
conversation more into a project management perspective:
* How can we advance CEP-7 so that the bulk of the SAI code can still be
added to Cassandra, so that  users can benefit from this new index type,
albeit without OR?
* This is also an important question from the point of view that this is a
large block of code that will inevitably diverged if it's not in trunk.
Also, merging it to trunk will allow future enhancements, including the OR
syntax btw, to happen against trunk (aka upstream first).
* Since OR support nevertheless is a feature of SAI, it needs to be at
least unit tested, but ideally even would be exposed so that it is possible
to test on the CQL level. Is there some mechanism such as experimental
flags, which would allow the SAI-only OR support to be merged into trunk,
while a separate CEP is focused on implementing "proper" general purpose OR
support? I should note that there is no guarantee that the OR CEP would be
implemented in time for the next release. So the answer to this point needs
to be something that doesn't violate the desire for good user experience.

henrik