Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

[Abe Ratnofsky]

Hardware acceleration for more things would be great, especially based on the 
success of ACCP (CASSANDRA-18624 
). But I think it would 
be ideal to use existing compressor names and use hardware acceleration if a 
given JAR is present on the classpath / configured, like ACCP. Then hosts with 
varying hardware acceleration support can still interoperate (stream compressed 
SSTables between each other, for example) and migrating existing systems to use 
the new compressors would be as simple as ensuring a JAR is present / 
configured, not requiring a change to table options.

See org.apache.cassandra.security.DefaultCryptoProvider for example.

> On Jan 19, 2024, at 1:51 PM, Kokoori, Shylaja  
> wrote:
> 
> Hi,
> Latest processors have integrated hardware accelerators which can speed up 
> operations like compress/decompress, crypto and analytics. Here are some 
> links to details
> 1) https://cdrdv2.intel.com/v1/dl/getContent/721858
> 2) 
> https://www.intel.com/content/www/us/en/content-details/780887/intel-in-memory-analytics-accelerator-intel-iaa.html
>  
> We would like to add a new compressor which can accelerate 
> compress/decompress when hardware is available and which will default to 
> software otherwise.
>  
> Thanks,
> Shylaja

[DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[C. Scott Andreas]

Hi all, I'd like to propose appending the following two footers to messages sent to the user@ and 
dev@ lists. The proposed postscript including line breaks is between the "X" blocks 
below. User List Footer: X --- Unsubscribe: Send a blank email to 
user-unsubscr...@cassandra.apache.org . Do not reply to this message. Cassandra Community: Follow 
other mailing lists or join us in Slack: https://cassandra.apache.org/_/community.html X Dev 
List Footer: X --- Unsubscribe: Send a blank email to dev-unsubscr...@cassandra.apache.org . Do 
not reply to this message. Cassandra Community: Follow other mailing lists or join us in Slack: 
https://cassandra.apache.org/_/community.html X Offering this proposal for three reasons: – 
Many users are sending "Unsubscribe" messages to the full mailing list which prompts 
others to wish to unsubscribe – a negative cascade that affects the size of our user community. – 
Many users don't know where to go to figure out how to unsubscribe, especially if they'd joined 
many years ago. – Nearly all mailing lists provide a one-click mechanism for unsubscribing or 
built-in mail client integration to do so via message headers. Including compact instructions on 
how to leave is valuable to subscribers. #asfinfra indicates that such footers can be appended 
given project consensus and an INFRA- ticket: 
https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079 If we reach consensus on adding a 
message footer, I'll file an INFRA ticket with a link to this thread. Thanks, – Scott

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[Brandon Williams]

+1

Kind Regards,
Brandon

On Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas  wrote:
>
> Hi all,
>
> I'd like to propose appending the following two footers to messages sent to 
> the user@ and dev@ lists. The proposed postscript including line breaks is 
> between the "X" blocks below.
>
> User List Footer:
> X
>
> ---
> Unsubscribe: Send a blank email to user-unsubscr...@cassandra.apache.org. Do 
> not reply to this message.
> Cassandra Community: Follow other mailing lists or join us in Slack: 
> https://cassandra.apache.org/_/community.html
> X
>
> Dev List Footer:
> X
>
> ---
> Unsubscribe: Send a blank email to dev-unsubscr...@cassandra.apache.org. Do 
> not reply to this message.
> Cassandra Community: Follow other mailing lists or join us in Slack: 
> https://cassandra.apache.org/_/community.html
> X
>
> Offering this proposal for three reasons:
> – Many users are sending "Unsubscribe" messages to the full mailing list 
> which prompts others to wish to unsubscribe – a negative cascade that affects 
> the size of our user community.
> – Many users don't know where to go to figure out how to unsubscribe, 
> especially if they'd joined many years ago.
> – Nearly all mailing lists provide a one-click mechanism for unsubscribing or 
> built-in mail client integration to do so via message headers. Including 
> compact instructions on how to leave is valuable to subscribers.
>
> #asfinfra indicates that such footers can be appended given project consensus 
> and an INFRA- ticket: 
> https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079
>
> If we reach consensus on adding a message footer, I'll file an INFRA ticket 
> with a link to this thread.
>
> Thanks,
>
> – Scott
>

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[J. D. Jordan]

I think we used to have this and removed them because it was breaking the 
encryption signature on messages or something which meant they were very likely 
to be treated as spam?

Not saying we can’t put it back on, but it was removed for good reasons from 
what I recall.

> On Jan 22, 2024, at 12:19 PM, Brandon Williams  wrote:
> 
> +1
> 
> Kind Regards,
> Brandon
> 
>> On Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas  
>> wrote:
>> 
>> Hi all,
>> 
>> I'd like to propose appending the following two footers to messages sent to 
>> the user@ and dev@ lists. The proposed postscript including line breaks is 
>> between the "X" blocks below.
>> 
>> User List Footer:
>> X
>> 
>> ---
>> Unsubscribe: Send a blank email to user-unsubscr...@cassandra.apache.org. Do 
>> not reply to this message.
>> Cassandra Community: Follow other mailing lists or join us in Slack: 
>> https://cassandra.apache.org/_/community.html
>> X
>> 
>> Dev List Footer:
>> X
>> 
>> ---
>> Unsubscribe: Send a blank email to dev-unsubscr...@cassandra.apache.org. Do 
>> not reply to this message.
>> Cassandra Community: Follow other mailing lists or join us in Slack: 
>> https://cassandra.apache.org/_/community.html
>> X
>> 
>> Offering this proposal for three reasons:
>> – Many users are sending "Unsubscribe" messages to the full mailing list 
>> which prompts others to wish to unsubscribe – a negative cascade that 
>> affects the size of our user community.
>> – Many users don't know where to go to figure out how to unsubscribe, 
>> especially if they'd joined many years ago.
>> – Nearly all mailing lists provide a one-click mechanism for unsubscribing 
>> or built-in mail client integration to do so via message headers. Including 
>> compact instructions on how to leave is valuable to subscribers.
>> 
>> #asfinfra indicates that such footers can be appended given project 
>> consensus and an INFRA- ticket: 
>> https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079
>> 
>> If we reach consensus on adding a message footer, I'll file an INFRA ticket 
>> with a link to this thread.
>> 
>> Thanks,
>> 
>> – Scott
>> 

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[Jeremiah Jordan]

Here was the thread where it was removed:lists.apache.orgOn Jan 22, 2024, at 12:37 PM, J. D. Jordan  wrote:I think we used to have this and removed them because it was breaking the encryption signature on messages or something which meant they were very likely to be treated as spam?Not saying we can’t put it back on, but it was removed for good reasons from what I recall.On Jan 22, 2024, at 12:19 PM, Brandon Williams  wrote:+1Kind Regards,BrandonOn Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas  wrote:Hi all,I'd like to propose appending the following two footers to messages sent to the user@ and dev@ lists. The proposed postscript including line breaks is between the "X" blocks below.User List Footer:X---Unsubscribe: Send a blank email to user-unsubscr...@cassandra.apache.org. Do not reply to this message.Cassandra Community: Follow other mailing lists or join us in Slack: https://cassandra.apache.org/_/community.htmlXDev List Footer:X---Unsubscribe: Send a blank email to dev-unsubscr...@cassandra.apache.org. Do not reply to this message.Cassandra Community: Follow other mailing lists or join us in Slack: https://cassandra.apache.org/_/community.htmlXOffering this proposal for three reasons:– Many users are sending "Unsubscribe" messages to the full mailing list which prompts others to wish to unsubscribe – a negative cascade that affects the size of our user community.– Many users don't know where to go to figure out how to unsubscribe, especially if they'd joined many years ago.– Nearly all mailing lists provide a one-click mechanism for unsubscribing or built-in mail client integration to do so via message headers. Including compact instructions on how to leave is valuable to subscribers.#asfinfra indicates that such footers can be appended given project consensus and an INFRA- ticket: https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079If we reach consensus on adding a message footer, I'll file an INFRA ticket with a link to this thread.Thanks,– Scott

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[Bowen Song via dev]

Adding a footer or modifying the email content in any way will break the 
DKIM signature of the email if it has one. Since the mailing list's mail 
server will forward the emails to the recipients, the SPF check will 
fail too. Failing the DKIM signature & SPF check will result in the 
email likely being treated as spam and either end up in the spam/junk 
mailbox or being rejected by recipients' mail server. The DMARC standard 
also requires at least one of the DKIM signature and SPF check must 
pass, otherwise it is considered as a failure. If the sender domain has 
a valid DMARC rule to reject or quarantine the failing emails, the 
mailing list subscribers with a mail service provider supporting the 
DMARC standard will never see any email from these senders via the 
mailing list landing in their inbox.


Balancing the pros and cons, I believe it's better to have small number 
of users occasionally spamming the mailing lists with invalid 
unsubscription emails than having the vast majority of users unable to 
receive emails from a subset of users (e.g. anyone from the @yahoo.com 
domain, or myself).


On 22/01/2024 18:10, C. Scott Andreas wrote:

Hi all,

I'd like to propose appending the following two footers to messages 
sent to the user@ and dev@ lists. The proposed postscript including 
line breaks is between the "X" blocks below.


User List Footer:
X

---
Unsubscribe: Send a blank email to 
user-unsubscr...@cassandra.apache.org. Do not reply to this message.
Cassandra Community: Follow other mailing lists or join us in Slack: 
https://cassandra.apache.org/_/community.html

X

Dev List Footer:
X

---
Unsubscribe: Send a blank email to 
dev-unsubscr...@cassandra.apache.org. Do not reply to this message.
Cassandra Community: Follow other mailing lists or join us in Slack: 
https://cassandra.apache.org/_/community.html

X

Offering this proposal for three reasons:
– Many users are sending "Unsubscribe" messages to the full mailing 
list which prompts others to wish to unsubscribe – a negative cascade 
that affects the size of our user community.
– Many users don't know where to go to figure out how to unsubscribe, 
especially if they'd joined many years ago.
– Nearly all mailing lists provide a one-click mechanism for 
unsubscribing or built-in mail client integration to do so via message 
headers. Including compact instructions on how to leave is valuable to 
subscribers.


#asfinfra indicates that such footers can be appended given project 
consensus and an INFRA- ticket: 
https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079


If we reach consensus on adding a message footer, I'll file an INFRA 
ticket with a link to this thread.


Thanks,

– Scott

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[Brandon Williams]

That's right, I'd forgotten about this.  I change my +1 to -1, there's not
enough value in this to break signatures.

Kind Regards,
Brandon


On Mon, Jan 22, 2024 at 12:42 PM Jeremiah Jordan 
wrote:

> Here was the thread where it was removed:
> lists.apache.org
> 
> [image: favicon.ico]
> 
> 
>
>
> On Jan 22, 2024, at 12:37 PM, J. D. Jordan 
> wrote:
>
> I think we used to have this and removed them because it was breaking
> the encryption signature on messages or something which meant they were
> very likely to be treated as spam?
>
> Not saying we can’t put it back on, but it was removed for good reasons
> from what I recall.
>
> On Jan 22, 2024, at 12:19 PM, Brandon Williams  wrote:
>
>
> +1
>
>
> Kind Regards,
>
> Brandon
>
>
> On Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas 
> wrote:
>
>
> Hi all,
>
>
> I'd like to propose appending the following two footers to messages sent
> to the user@ and dev@ lists. The proposed postscript including line
> breaks is between the "X" blocks below.
>
>
> User List Footer:
>
> X
>
>
> ---
>
> Unsubscribe: Send a blank email to user-unsubscr...@cassandra.apache.org.
> Do not reply to this message.
>
> Cassandra Community: Follow other mailing lists or join us in Slack:
> https://cassandra.apache.org/_/community.html
>
> X
>
>
> Dev List Footer:
>
> X
>
>
> ---
>
> Unsubscribe: Send a blank email to dev-unsubscr...@cassandra.apache.org.
> Do not reply to this message.
>
> Cassandra Community: Follow other mailing lists or join us in Slack:
> https://cassandra.apache.org/_/community.html
>
> X
>
>
> Offering this proposal for three reasons:
>
> – Many users are sending "Unsubscribe" messages to the full mailing list
> which prompts others to wish to unsubscribe – a negative cascade that
> affects the size of our user community.
>
> – Many users don't know where to go to figure out how to unsubscribe,
> especially if they'd joined many years ago.
>
> – Nearly all mailing lists provide a one-click mechanism for unsubscribing
> or built-in mail client integration to do so via message headers. Including
> compact instructions on how to leave is valuable to subscribers.
>
>
> #asfinfra indicates that such footers can be appended given project
> consensus and an INFRA- ticket:
> https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079
>
>
> If we reach consensus on adding a message footer, I'll file an INFRA
> ticket with a link to this thread.
>
>
> Thanks,
>
>
> – Scott
>
>
>


favicon.ico
Description: Binary data

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[C. Scott Andreas]

Bowen and Jeremiah, thanks for remembering this. I'd remembered the DKIM/SPF issue, but not its relationship to the message footer - 
appreciate your work fixing that, Bowen. I'm part of a few Google Groups that relay messages with an appended footer that don't seem to 
encounter invalidation, but am not curious enough to learn how they make that work right now. :) I withdraw the proposal. 👍 – Scott On 
Jan 22, 2024, at 10:56 AM, Brandon Williams  wrote: That's right, I'd forgotten about this. I change my +1 to 
-1, there's not enough value in this to break signatures. Kind Regards, Brandon On Mon, Jan 22, 2024 at 12:42 PM Jeremiah Jordan < 
jerem...@datastax.com > wrote: Here was the thread where it was removed: lists.apache.org On Jan 22, 2024, at 12:37 PM, J. D. Jordan 
< jeremiah.jor...@gmail.com > wrote: I think we used to have this and removed them because it was breaking the encryption 
signature on messages or something which meant they were very likely to be treated as spam? Not saying we can’t put it back on, but it 
was removed for good reasons from what I recall. On Jan 22, 2024, at 12:19 PM, Brandon Williams < dri...@gmail.com > wrote: +1 
Kind Regards, Brandon On Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas < sc...@paradoxica.net > wrote: Hi all, I'd like to 
propose appending the following two footers to messages sent to the user@ and dev@ lists. The proposed postscript including line breaks 
is between the "X" blocks below. User List Footer: X --- Unsubscribe: Send a blank email to 
user-unsubscr...@cassandra.apache.org . Do not reply to this message. Cassandra Community: Follow other mailing lists or join us in 
Slack: https://cassandra.apache.org/_/community.html X Dev List Footer: X --- Unsubscribe: Send a blank email to 
dev-unsubscr...@cassandra.apache.org . Do not reply to this message. Cassandra Community: Follow other mailing lists or join us in 
Slack: https://cassandra.apache.org/_/community.html X Offering this proposal for three reasons: – Many users are sending 
"Unsubscribe" messages to the full mailing list which prompts others to wish to unsubscribe – a negative cascade that affects 
the size of our user community. – Many users don't know where to go to figure out how to unsubscribe, especially if they'd joined many 
years ago. – Nearly all mailing lists provide a one-click mechanism for unsubscribing or built-in mail client integration to do so via 
message headers. Including compact instructions on how to leave is valuable to subscribers. #asfinfra indicates that such footers can 
be appended given project consensus and an INFRA- ticket: https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079 If we reach 
consensus on adding a message footer, I'll file an INFRA ticket with a link to this thread. Thanks, – Scott 

Re: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

[Dinesh Joshi]

Shylaja,

Cassandra uses ZStd, LZ4 and other compression libraries via JNI to
compress data. The intel hardware accelerator support is integrated into
those libraries and we can benefit from it. If there are special parameters
that need to be passed in to these libraries we can make those changes on
the database but as such Cassandra does not directly implement the
compression algorithms itself.

Dinesh

Re: [DISCUSS] Add subscription mangement instructions to user@, dev@ message footers

[Bowen Song via dev]

Google Group works slightly differently. They "forward" emails using the 
group's email address as the "From" address, not the original sender's 
email address, unless the sender address happen to be a Google mail 
address (including Gmail and others). Technically speaking, that's not 
forwarding, but sending a new email with the original email's content, 
subject, sender name (but not address), etc. information copied over.


I believe the mailing list software this mailing list is using also 
supports such feature. For example, this email's "From" address is 
"Bowen Song via dev ", not my actual email 
address (which is the "Cc" address). If we add the footer to all emails, 
all "From" addresses, other than those Apache email addresses (e.g. 
f...@apache.org), will have to be turned into "dev@cassandra.apache.org". 
This works, but there's a catch. Many people (habitually) hits the 
"reply all" button on their mail client instead of the "reply" button, 
and as a result of that, the person being replied to will receive two 
nearly identical emails, one addressed to the mailing list which is then 
modified to added the footer, and the other Cc-ed to them without the 
footer. This may turn out to be very annoying if a mailing list 
participant can't (or doesn't know how to) setup inbox rules to filter 
these out.


There's no "Prefect Solution™", unsurprisingly.


On 22/01/2024 19:08, C. Scott Andreas wrote:

Bowen and Jeremiah, thanks for remembering this.

I'd remembered the DKIM/SPF issue, but not its relationship to the 
message footer - appreciate your work fixing that, Bowen.


I'm part of a few Google Groups that relay messages with an appended 
footer that don't seem to encounter invalidation, but am not curious 
enough to learn how they make that work right now. :)


I withdraw the proposal. 👍

– Scott


On Jan 22, 2024, at 10:56 AM, Brandon Williams  wrote:


That's right, I'd forgotten about this.  I change my +1 to -1, 
there's not enough value in this to break signatures.


Kind Regards,
Brandon


On Mon, Jan 22, 2024 at 12:42 PM Jeremiah Jordan 
 wrote:



Here was the thread where it was removed:
lists.apache.org

favicon.ico




On Jan 22, 2024, at 12:37 PM, J. D. Jordan
 wrote:
I think we used to have this and removed them because it was
breaking the encryption signature on messages or something which
meant they were very likely to be treated as spam?

Not saying we can’t put it back on, but it was removed for good
reasons from what I recall.


On Jan 22, 2024, at 12:19 PM, Brandon Williams
 wrote:

+1

Kind Regards,
Brandon


On Mon, Jan 22, 2024 at 12:10 PM C. Scott Andreas
 wrote:

Hi all,

I'd like to propose appending the following two footers to
messages sent to the user@ and dev@ lists. The proposed
postscript including line breaks is between the "X" blocks
below.

User List Footer:
X

---
Unsubscribe: Send a blank email to
user-unsubscr...@cassandra.apache.org. Do not reply to this
message.
Cassandra Community: Follow other mailing lists or join us in
Slack: https://cassandra.apache.org/_/community.html
X

Dev List Footer:
X

---
Unsubscribe: Send a blank email to
dev-unsubscr...@cassandra.apache.org. Do not reply to this
message.
Cassandra Community: Follow other mailing lists or join us in
Slack: https://cassandra.apache.org/_/community.html
X

Offering this proposal for three reasons:
– Many users are sending "Unsubscribe" messages to the full
mailing list which prompts others to wish to unsubscribe – a
negative cascade that affects the size of our user community.
– Many users don't know where to go to figure out how to
unsubscribe, especially if they'd joined many years ago.
– Nearly all mailing lists provide a one-click mechanism for
unsubscribing or built-in mail client integration to do so via
message headers. Including compact instructions on how to
leave is valuable to subscribers.

#asfinfra indicates that such footers can be appended given
project consensus and an INFRA- ticket:
https://the-asf.slack.com/archives/CBX4TSBQ8/p1705939868631079

If we reach consensus on adding a message footer, I'll file an
INFRA ticket with a link to this thread.

Thanks,

– Scott

RE: CASSANDRA-19268: Improve Cassandra compression performance using hardware accelerators

[Kokoori, Shylaja]

Dinesh & Abe,
Thank you very much for your feedback.

The algorithm used by this HW compressor is compatible with Deflate but there 
is a constraint of 4K window size. Therefore the concern is that existing data 
may not decompress correctly as is. That is why we chose the path of adding a 
new compressor.
Another reason is that, there are some additional features available in the 
hardware which are not compatible with zlib. With this approach we could enable 
those features as well.

We are also planning to accelerate existing compressors, if that is the 
preferred approach we will try to come up with a solution to work around the 4k 
window limitation.

Thank you,
Shylaja

From: Dinesh Joshi 
Sent: Monday, January 22, 2024 11:18 AM
To: dev@cassandra.apache.org
Subject: Re: CASSANDRA-19268: Improve Cassandra compression performance using 
hardware accelerators

Shylaja,

Cassandra uses ZStd, LZ4 and other compression libraries via JNI to compress 
data. The intel hardware accelerator support is integrated into those libraries 
and we can benefit from it. If there are special parameters that need to be 
passed in to these libraries we can make those changes on the database but as 
such Cassandra does not directly implement the compression algorithms itself.

Dinesh

Re: [VOTE] Release Apache Cassandra 4.0.12

[Paulo Motta]

+1

Tested docker image build (binary+checksum+signature) and container startup
with:

$ docker build --build-arg CASSANDRA_VERSION=4.0.12 --build-arg
CASSANDRA_SHA512=65de9cc32f3d22d55f5c7c3b1417285a41aabb70fa8a4ae8d9d85a58e644f43151bf4f386cc45773b6ac317db38c4576b139ca6b6fcdbbd16993d09ee2a5c2b8
https://github.com/pauloricardomg/docker-cassandra.git#:4.0
$ docker run apache/cassandra-test:4.0.12  -f

On Fri, Jan 19, 2024 at 6:30 PM Brandon Williams  wrote:

> +1
>
> Kind Regards,
> Brandon
>
> On Thu, Jan 18, 2024 at 5:56 AM Štefan Miklošovič
>  wrote:
> >
> > Proposing the test build of Cassandra 4.0.12 for release.
> >
> > sha1: af752fcd535ccdac69b9fed88047b2dd7625801e
> > Git: https://github.com/apache/cassandra/tree/4.0.12-tentative
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1323/org/apache/cassandra/cassandra-all/4.0.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/4.0.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://github.com/apache/cassandra/blob/4.0.12-tentative/CHANGES.txt
> > [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/4.0.12-tentative/NEWS.txt
>

Re: [VOTE] Release Apache Cassandra 4.0.12

[Paulo Motta]

Oops, omitted "-t apache/cassandra-test:4.0.12" arg from the first command
in the previous message 😀 - corrected verification script is:

$ docker build -t apache/cassandra-test:4.0.12 --build-arg
CASSANDRA_VERSION=4.0.12 --build-arg
CASSANDRA_SHA512=65de9cc32f3d22d55f5c7c3b1417285a41aabb70fa8a4ae8d9d85a58e644f43151bf4f386cc45773b6ac317db38c4576b139ca6b6fcdbbd16993d09ee2a5c2b8
https://github.com/pauloricardomg/docker-cassandra.git#:4.0
$ sudo docker run apache/cassandra-test:4.0.12  -f

On Mon, Jan 22, 2024 at 11:08 PM Paulo Motta  wrote:

> +1
>
> Tested docker image build (binary+checksum+signature) and container
> startup with:
>
> $ docker build --build-arg CASSANDRA_VERSION=4.0.12 --build-arg
> CASSANDRA_SHA512=65de9cc32f3d22d55f5c7c3b1417285a41aabb70fa8a4ae8d9d85a58e644f43151bf4f386cc45773b6ac317db38c4576b139ca6b6fcdbbd16993d09ee2a5c2b8
> https://github.com/pauloricardomg/docker-cassandra.git#:4.0
> $ docker run apache/cassandra-test:4.0.12  -f
>
> On Fri, Jan 19, 2024 at 6:30 PM Brandon Williams  wrote:
>
>> +1
>>
>> Kind Regards,
>> Brandon
>>
>> On Thu, Jan 18, 2024 at 5:56 AM Štefan Miklošovič
>>  wrote:
>> >
>> > Proposing the test build of Cassandra 4.0.12 for release.
>> >
>> > sha1: af752fcd535ccdac69b9fed88047b2dd7625801e
>> > Git: https://github.com/apache/cassandra/tree/4.0.12-tentative
>> > Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1323/org/apache/cassandra/cassandra-all/4.0.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/4.0.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://github.com/apache/cassandra/blob/4.0.12-tentative/CHANGES.txt
>> > [2]: NEWS.txt:
>> https://github.com/apache/cassandra/blob/4.0.12-tentative/NEWS.txt
>>
>

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

[Jaydeep Chovatia]

Hi Jon and Jeff,

First of all sorry for the late reply as I got a bit busy with a production
bug we have discovered in 4.0
https://issues.apache.org/jira/browse/CASSANDRA-17401, please see if you or
someone could prioritize the review of the submitted PR.

Thanks for your valuable feedback!

I just think there's a ton more value in the drivers being able to throttle
requests to deal than server side.

There is no denying that we can do a ton of things on the client side as
far as the rate limiter is concerned, but the server has more fine-grained
indicators, so if we tackle the server-side first, then we will get a lot
of benefits. In an ideal world, we would need rate limiters at various
layers, i.e., at server layer and at the client layers.

Yes, I agree using dropped metrics (errors) is useful, as well as queue
length.  I can't remember offhand all the details of the request queue and
how load shedding works there, I need to go back and look.  If we don't
already have load shedding based on queue depth that seems like an easy
thing to do immediately, and is a high quality signal.  Maybe someone can
remind me if we have that already?

The Cassandra queues, especially, pending reads, mutations, and transport
queues usually indicate some serious slowdowns.

My issue with using CPU to rate limit clients is that I think it's a very
low quality signal, and I suspect it'll trigger a ton of false positives.

In the rate limiter, CPU is not only going to be the only source, but it
will be one of the key indicators. Along with the CPU, we will consider
Cassandra internal queues as well and then make a decision on whether a
server node is running hot or not.

Again, the "Generic" name I have given of this project might be
misleading. This is not the full and final rate limiter implementation for
Cassandra, but one step towards protecting the Cassandra server due to the
slowdowns caused by the clients, such as pushing 10x load, reading/writing
large partitions, tombstones, etc. On purpose, in this design, we are not
touching system activities such as compaction, system traffic, etc. because
they are essential for Cassandra server to stay alive. For sure, we can
enhance this framework in future and make it more smarter and smarter so
that it will be able to predict the cause of the slowdowns and then apply
back pressure depending upon the situations, such as user traffic or
compaction or repair, etc.
But in the first phase, the target is the slowdowns caused by client
traffic, and especially avoid ripple effect on the entire Cassandra server
ring, e.g., a few hot nodes eventually slowing down the entire cluster.

Jaydeep



On Thu, Jan 18, 2024 at 8:24 PM Jon Haddad  wrote:

> > The problem with generalizing things is if you’re behind on compaction,
> reads get expensive, so you pause compaction completely, you’re SOL and
> you’ll eventually have to throttle traffic to recover
>
> Yeah - there's definitely quite a few ways this can go sideways, and this
> is a good example that won't be consistent across deployments.  There's a
> lot of variables to consider.  I agree that building the machinery for
> operators to make adjustments is the right first step.  Assuming we get all
> the rate limiting options available over CQL and stats available via
> virtual tables, operators can make whatever decisions they feel is best,
> and we'd hopefully get some good feedback about what works well and what
> doesn't.
>
> Jon
>
>
>
>
> On Thu, Jan 18, 2024 at 4:16 PM Jeff Jirsa  wrote:
>
>> The problem with generalizing things is if you’re behind on compaction,
>> reads get expensive, so you pause compaction completely, you’re SOL and
>> you’ll eventually have to throttle traffic to recover
>>
>> The SEDA model is bad at back pressure and deferred cost makes it
>> non-obvious which resource to slow to ensure stability
>>
>> Just start by exposing it instead of pretending we can outsmart the very
>> complex system
>>
>> On Jan 18, 2024, at 4:56 PM, Jon Haddad  wrote:
>>
>> 
>> I am definitely +1 on the ability to rate limit operations to tables and
>> keyspaces, and if we can do it at a granular level per user I'm +1 to that
>> as well.  I think this would need to be exposed to the operator regardless
>> of any automatic rate limiter.
>>
>> Thinking about the bigger picture for a minute, I think there's a few
>> things we could throttle dynamically on the server before limiting the
>> client requests.  I've long wanted to see a dynamic rate limiter with
>> compaction and any streaming operation - using resources when they're
>> available but slowing down to allow an influx of requests.  Being able to
>> throttle background operations to free up resources to ensure the DB stays
>> online and healthy would be a big win.
>>
>> > The major challenge with latency based rate limiters is that the
>> latency is subjective from one workload to another.
>>
>> You're absolutely right.  This goes to my other suggestion that
>> client-side r