[
https://issues.apache.org/jira/browse/CASSANDRA-18799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17776713#comment-17776713
]
Maxim Muzafarov commented on CASSANDRA-18799:
---------------------------------------------
Hi [~aweisberg], I appreciate you analyzing this ticket and pointing out the
things we should pay additional attention to. So, the issue originally came
from the idea to remove unused dependencies (like the {{{}ohc-core-j8{}}})
after dropping the {{jdk8}} support, but it quickly turned out that the ohc
library version needs to be updated as well. You mentioned the UnsTest above, I
can reproduce the `testDecrementIncrement` failure on my arm64 environment with
an exception "java.lang.InternalError: a fault occurred in a recent unsafe
memory access operation in compiled Java code".
However, my biggest concern is related to the JNA dependency on the ohc
library. We are now using version {{0.5.1}} of the ohc library in Cassandra.
The ohc {{0.5.1}} depends on version {{4.1.0}} [1] of the {{net.java.dev.jna}}
. For the Cassandra project, JNA has been updated since the 4.0 release version
up to JNA {{5.6.0}} in CASSANDRA-16212 to support running nodes on the
{{arm64}} architecture, so I assume that JNA 4.1.0 is no longer in Casssandra's
classpath. Considering the fact that the JNANativeAllocator is a default one
[2] for the ohc, and I haven't found any places where the
{{'org.caffinitas.ohc.allocator="unsafe"'}} is specified we could possibly get
a runtime error on the arm64 architecture when Config.row_cache_size is set
greater than zero (meaning the ohc is enabled), because the JNA 5.6.0 and JNA
4.1.0 are not compatible, and the breaking changes [3] exist in between. This,
in turn, could be very dangerous for production environments.
The 0.7.4. ohc depends on JNA 5.10.0, so I guess the above problem shouldn't be
raised after the update. If I'm wrong in my concerns, please correct me. I also
support your point about having reliable eviction policy tests, so we can
easily trust the test results and improve if any concerns arise.
So the question here is, should we move the ohc under the ASF first or do the
update?
WDYT?
[1] [https://github.com/snazy/ohc/blob/0.5.1/pom.xml#L81]
[2]
[https://github.com/snazy/ohc/blob/0.5.1/ohc-core/src/main/java/org/caffinitas/ohc/linked/Uns.java#L192]
[3]
[https://github.com/java-native-access/jna/blob/5.6.0/CHANGES.md#breaking-changes]
The stack trace of the `testDecrementIncrement` is for visibility:
{code:java}
java.lang.InternalError: a fault occurred in a recent unsafe memory access
operation in compiled Java code
at org.testng.Assert.failNotEquals(Assert.java:1037)
at org.testng.Assert.assertEqualsImpl(Assert.java:140)
at org.testng.Assert.assertEquals(Assert.java:122)
at org.testng.Assert.assertEquals(Assert.java:797)
at
org.caffinitas.ohc.linked.UnsTest.testDecrementIncrement(UnsTest.java:395)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:133)
at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:598)
at
org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:173)
at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
at
org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:824)
at
org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:146)
at
org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at org.testng.TestRunner.privateRun(TestRunner.java:794)
at org.testng.TestRunner.run(TestRunner.java:596)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:377)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:371)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:332)
at org.testng.SuiteRunner.run(SuiteRunner.java:276)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1212)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1134)
at org.testng.TestNG.runSuites(TestNG.java:1063)
at org.testng.TestNG.run(TestNG.java:1031)
at com.intellij.rt.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:66)
at
com.intellij.rt.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:109)
{code}
> Remove org.caffinitas.ohc:ohc-core-j8 dependency
> ------------------------------------------------
>
> Key: CASSANDRA-18799
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18799
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
> Reporter: Maxim Muzafarov
> Assignee: Maxim Muzafarov
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems the `org.caffinitas.ohc:ohc-core-j8` is not required anymore and the
> Cassandra project moved away from JDK8 support. The changes are here:
> CASSANDRA-18255
> We can remove it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
