Re: [ANNOUNCE] Apache Cassandra 4.1.4 test artifact available

[Berenguer Blasi]

Hi all,

CASSANDRA-19097 has been lowered from critical now that it has been 
analyzed. It is no longer a release blocker.


Regards

On 24/1/24 8:30, Fleming, Jackson via dev wrote:


Sorry centered not “cantered”

*From: *Fleming, Jackson 
*Date: *Wednesday, 24 January 2024 at 6:29 pm
*To: *dev@cassandra.apache.org 
*Subject: *Re: [ANNOUNCE] Apache Cassandra 4.1.4 test artifact available

Silly question but there was just a 4.0.12 release, should users avoid 
adopting that or is the concern more cantered around CI and testing? 
Does a 4.0.13 need to be considered?


Regards,

**

*Jackson *

*From: *Berenguer Blasi 
*Date: *Wednesday, 24 January 2024 at 5:01 pm
*To: *dev@cassandra.apache.org 
*Subject: *Re: [ANNOUNCE] Apache Cassandra 4.1.4 test artifact available

EXTERNAL EMAIL - USE CAUTION when clicking links or attachments




-1

I just raised CASSANDRA-19097 (4.0->5.0) to critical. Basically we fail
to bootstrap correctly and even reading at ALL after bootstrapping fails
to get the correct data. We didn't manage to repro and the failure looks
recently-ish. Any help from anybody familiar with that area of the code
welcomed.

On 23/1/24 21:03, Štefan Miklošovič wrote:
> The test build of Cassandra 4.1.4 is available.
>
> sha1: 99d9faeef57c9cf5240d11eac9db5b283e45a4f9
> Git: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Ftree%2F4.1.4-tentative&data=05%7C02%7CJackson.Fleming%40netapp.com%7C10377795a91d48276c3508dc1ca1ef7a%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638416729039426249%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h3FePlwdJ%2FraIzDFbTx19O%2FHprnaVp5HI5h2aPsRka0%3D&reserved=0 


> Maven Artifacts:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachecassandra-1324%2Forg%2Fapache%2Fcassandra%2Fcassandra-all%2F4.1.4%2F&data=05%7C02%7CJackson.Fleming%40netapp.com%7C10377795a91d48276c3508dc1ca1ef7a%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638416729039434078%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=y7UPElrhi6bfcp3MQ2s85ew9QqHC5PEbrq9JObPfK5o%3D&reserved=0 


>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fcassandra%2F4.1.4%2F&data=05%7C02%7CJackson.Fleming%40netapp.com%7C10377795a91d48276c3508dc1ca1ef7a%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638416729039439313%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LrLUJMbOA%2F7zmVMNTZYIEoSUxyxTAxV7jJ2EvfCiSQ8%3D&reserved=0 


>
> A vote of this test build will be initiated within the next couple of
> days.
>
> [1]: CHANGES.txt:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Fblob%2F4.1.4-tentative%2FCHANGES.txt&data=05%7C02%7CJackson.Fleming%40netapp.com%7C10377795a91d48276c3508dc1ca1ef7a%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638416729039443868%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YOCYEmnPTvVBxu02bDZZDTEu0X6VKV2AzzZNK7Hqbo0%3D&reserved=0 


> [2]: NEWS.txt:
> 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcassandra%2Fblob%2F4.1.4-tentative%2FNEWS.txt&data=05%7C02%7CJackson.Fleming%40netapp.com%7C10377795a91d48276c3508dc1ca1ef7a%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638416729039449154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8k3POE7iCo4b6EEKEgkgEcoIHzGFA2fIQu3QkESDBK8%3D&reserved=0 

[VOTE] Release Apache Cassandra 4.1.4

[Štefan Miklošovič]

Proposing the test build of Cassandra 4.1.4 for release.

sha1: 99d9faeef57c9cf5240d11eac9db5b283e45a4f9
Git: https://github.com/apache/cassandra/tree/4.1.4-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1324/org/apache/cassandra/cassandra-all/4.1.4/

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.1.4/

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.1.4-tentative/CHANGES.txt
[2]: NEWS.txt:
https://github.com/apache/cassandra/blob/4.1.4-tentative/NEWS.txt

JDK 22 RDP2 & Deprecate sun.misc.Unsafe Memory-Access Methods…

[David Delabassee]

Greetings!

We are starting 2024 with JDK 22 as it has just entered Rampdown Phase 2 [1]. 
And with the initial JDK 22 Release Candidates now less than 2 weeks away (Feb. 
8th) [2], it is time to shift our attention to JDK 23.

After multiple rounds of incubations and preview, the Foreign Function & Memory 
API is becoming standard and permanent in JDK 22. If we put its 'Function' 
angle aside, this API also offers a standard and secure way to access off-heap 
API. And that brings us to the heads-up below 'Deprecate the memory-access 
methods in sun.misc.Unsafe for removal in a future release' as developers still 
using sun.misc.Unsafe for accessing memory are strongly encouraged to start 
preparing their plans to migrate away from those unsafe methods.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-January/008675.html
[2] https://openjdk.org/projects/jdk/22/


## Heads-up: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal 
in a Future Release

The effort focused on enforcing the integrity of the Java platform [3] 
continues! The next phase in that long but important initiative will most 
likely target the sun.misc.Unsafe API used for accessing memory. Those methods 
alone represent 79 methods out of the 87 sun.misc.Unsafe methods!

This draft JEP [4] outlines the plan to deprecate for removal the 
sun.misc.Unsafe Memory-Access methods, the reasons, and the standard 
alternatives. As the draft plan suggests, the first step will be to deprecate 
all memory-access methods (on-heap, off-heap, and bimodal) for removal. This 
will cause compile-time deprecation warnings for code that refers to the 
methods, alerting library developers to their forthcoming removal. In addition, 
a new command-line option will allow users to receive runtime warnings when 
those methods are used. This command-line will help users to assess if their 
codebase uses those unsafe API to access memory. It should be mentioned that 
other tools such as JFR and jdeprscan can also be used to detect the use of 
those deprecated APIs.

Library developers are strongly encouraged to migrate from sun.misc.Unsafe to 
the supported replacements, so that applications can migrate smoothly to modern 
JDKs. The initial step will be to conduct investigations to understand if, how, 
and where sun.misc.Unsafe methods are used to access memory.

[3] https://openjdk.org/jeps/8305968
[4] https://openjdk.org/jeps/8323072


## Heads-up: Java Array Element Alignment - Weakening of Some Methods 
Guarantees ?

Some methods make promises about Java array element alignment that are too 
strong. There are some ongoing reflexions to change the implementation (and the 
specification) of `MethodHandles::byteArrayViewVarHandle`, 
`MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and 
`ByteBuffer::alignmentOffset` to weaken the guarantees they make about the 
alignment of Java array elements, in order to bring them in line with the 
guarantees made by an arbitrary JVM implementation.

For more details, make sure to check JDK-8320247 [5] and the related PR [6] but 
in a nutshell, the new behaviour would be :
- The `VarHandle` returned by `MethodHandles::byteArrayViewVarHandle` would 
only support `get` and `set` methods, and all other access methods would throw 
an exception.
- The `VarHandle` returned by `MethodHandles::byteBufferViewHandle` would only 
support the `get` and `set` access methods when a heap buffer is used, and all 
other access methods would throw an exception when used with a heap buffer. 
Direct byte buffers will continue to work the same way.
- The `ByteBuffer::alignmentOffset` and `ByteBuffer::alignedSlice` methods 
would throw an exception if the buffer is a heap buffer, and the given 
`unitSize` is greater than 1.

If you have relevant feedback about this potential change, please make sure to 
bring it to the core-libs-dev mailing list [7], or comment on the PR [6].

[5] https://bugs.openjdk.org/browse/JDK-8320247
[6] https://github.com/openjdk/jdk/pull/16681
[7] https://mail.openjdk.org/pipermail/core-libs-dev/


## JDK 22 Early-Access Builds

JDK 22 Early-Access builds 33 are now available [8], and are provided under the 
GNU General Public License v2, with the Classpath Exception. The Release Notes 
[9] and the javadocs [10] are also available.

### Changes in recent JDK 22 builds that may be of interest:

- JDK-8320597: RSA signature verification fails on signed data that does not 
encode params correctly [Reported by Apache POI]
- JDK-8322214: Return value of XMLInputFactory.getProperty() changed from 
boolean to String in JDK 22 early access builds [Reported by Apache POI]
- JDK-8322725: (tz) Update Timezone Data to 2023d
- JDK-8321480: ISO 4217 Amendment 176 Update
- JDK-8314468: Improve Compiler loops
- JDK-8314295: Enhance verification of verifier
- JDK-8316976: Improve signature handling
- JDK-8317547: Enhance TLS connection support
- JDK-8318971: Better Error Handling for Jar Tool When Process

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

[Caleb Rackliffe]

Hey all,

I'm a bit late to the discussion. I see that we've already discussed
CASSANDRA-15013  and
CASSANDRA-16663  at
least in passing. Having written the latter, I'd be the first to admit it's
a crude tool, although it's been useful here and there, and provides a
couple primitives that may be useful for future work. As Scott mentions,
while it is configurable at runtime, it is not adaptive, although we did
make configuration easier in CASSANDRA-17423
. It also is global
to the node, although we've lightly discussed some ideas around making it
more granular. (For example, keyspace-based limiting, or limiting "domains"
tagged by the client in requests, could be interesting.) It also does not
deal with inter-node traffic, of course.

Something we've not yet mentioned (that does address internode traffic) is
CASSANDRA-17324 ,
which I proposed shortly after working on the native request limiter (and
have just not had much time to return to). The basic idea is this:

When a node is struggling under the weight of a compaction backlog and
> becomes a cause of increased read latency for clients, we have two safety
> valves:
>
> 1.) Disabling the native protocol server, which stops the node from
> coordinating reads and writes.
> 2.) Jacking up the severity on the node, which tells the dynamic snitch to
> avoid the node for reads from other coordinators.
>
> These are useful, but we don’t appear to have any mechanism that would
> allow us to temporarily reject internode hint, batch, and mutation messages
> that could further delay resolution of the compaction backlog.
>

Whether it's done as part of a larger framework or on its own, it still
feels like a good idea.

Thinking in terms of opportunity costs here (i.e. where we spend our finite
engineering time to holistically improve the experience of operating this
database) is healthy, but we probably haven't reached the point of
diminishing returns on nodes being able to protect themselves from clients
and from other nodes. I would just keep in mind two things:

1.) The effectiveness of rate-limiting in the system (which includes the
database and all clients) as a whole necessarily decreases as we move from
the application to the lowest-level database internals. Limiting correctly
at the client will save more resources than limiting at the native protocol
server, and limiting correctly at the native protocol server will save more
resources than limiting after we've dispatched requests to some thread pool
for processing.
2.) We should make sure the links between the "known" root causes of
cascading failures and the mechanisms we introduce to avoid them remain
very strong.

In any case, I'd be happy to help out in any way I can as this moves
forward (especially as it relates to our past/current attempts to address
this problem space).