We gave it the second look and I came up with this (1) In a nutshell, we download both arch libs to libs/corretto and then cassandra.in.sh will dynamically resolve the architecture and OS. Based on that, it will add respective jar to the class path. If it went wrong and it is not added to CP, we just skip the installation / healthchecks as if nothing happened (by default).
We are also adding the dependency to Maven's pom.xml based on the architecture the build is invoked on so there is a possibility to create architecture-specific artifact. This is achieved by Maven profiles which are activated based on what architecture it is run. Hence, we covered both aspects, Maven build / dependencies as well as runtime library resolution. There is also flag added, "fail_on_missing_provider", which is by default false, if set to true, in case it was not on CP or if we by mistake installed different architecture, it will fail the startup. We could definitely use some review here, especially from people who run on ARM so we are sure that it works there as well as intended. (1) https://github.com/apache/cassandra/pull/2505/files ________________________________________ From: Mick Semb Wever <m...@apache.org> Sent: Friday, July 21, 2023 7:18 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] Using ACCP or tc-native by default NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. As I am on x86 and I wanted to simulate what would happen to users on ARM, I just did it other way around - I introduced the dependency with classifier linux-aarch_64. … Surprisingly, the installation step succeeded on x86 even the dependency was for aarch. However, the startup check went to else branch (2) and I saw that the provider was not Corretto provider but the default - SunJCE. So that tells me that it basically falls back to the default which is what we want. I raised concerns about this because we have no other dependencies that use the classifier in the pom file to bind us to a particular arch. The loading of the native code isn't my concern. I'm uneasy (without further investigation) with publishing cassandra pom files that classify us to " x86_64". For example, how the jar files differ between classifiers for this project. I'm also curious if there's a way to bundle the native files for all arch, like we do for other libraries, with runtime just loading what's correct.