[ https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723776#comment-17723776 ]
dan jatnieks commented on CASSANDRA-18180: ------------------------------------------ Recap: The {{attachment}} field of {{ByteBuffer}} is being used to store the related {{BufferPool}} {{Chunk}} object that is associated with the buffer. Since JDK11 some crypto overlap detection code in {{GaloisCounterMode}} expects that any object attached to a {{ByteBuffer}} implements {{{}DirectBuffer{}}}, and if it does not, will cause a {{{}ClassCastException{}}}. Since we see this {{ClassCastException}} in tests using encryption, it seems it's triggered by a supported TLS setting rather than some unintended default. The patch I provided uses the suggestion made by [~benedict] in this comment in CASSANDRA-17992, which is to have {{Chunk}} (and also {{{}Ref{}}}) implement {{{}DirectBuffer{}}}. The main downside to this is that two additional {{--add-exports}} are required to be able to access JDK internal class {{{}DirectBuffer{}}}. Access to this internal class also has a secondary impact on {{TestNameCheckTask}} as it uses reflection and tries to load all related classes of tests being checked. This led to replacing the {{checktestnameshelper}} ant task in {{build.xml}} with a java target so that it is possible to pass the needed jvm args to {{{}TestNameCheckTask{}}}. An alternative approach that avoids accessing jdk internals would, I think, still need to associate {{ByteBuffer}} objects to {{Chunk}} objects. I experimented with using a map for this, but ended up learning that {{{}ByteBuffer{}}}'s are not suited to being used as map keys, as the docs state: {noformat} because buffer hash codes are content-dependent, it is inadvisable to use buffers as keys in hash maps or similar data structures unless it is known that their contents will not change.{noformat} So, you can put a {{ByteBuffer}} into a map, but if the contents change you won't be able to retrieve/find it again. I'm not sure what other workaround solution to propose that doesn't negatively affect complexity and/or performance, but am happy to look into other ideas. There is another aspect of this that I don't fully understand that's somewhat bothersome - while this test fails with JDK17 and the same {{GaloisCounterMode}} overlap detection code is present in JDK11, only that code path is not executed and the tests pass with JDK11. So I wonder why that is? I did check the enabled cipher suites for internode messaging and native transport that I found looking at test run output - and those are the same with 11 and 17. So I guess it's a result of some change in the JDK? If I could be due to something else, I don't know what that might be. > bulkLoaderSuccessfullyStreamsOverSsl fails with ClassCastException on JDK17 > --------------------------------------------------------------------------- > > Key: CASSANDRA-18180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18180 > Project: Cassandra > Issue Type: Bug > Components: CI > Reporter: Ekaterina Dimitrova > Assignee: dan jatnieks > Priority: Normal > > While working on CASSANDRA-17992 we hit: > {code:java} > java.lang.ClassCastException: class > org.apache.cassandra.utils.memory.BufferPool$Chunk cannot be cast to class > sun.nio.ch.DirectBuffer (org.apache.cassandra.utils.memory.BufferPool$Chunk > is in unnamed module of loader 'app'; sun.nio.ch.DirectBuffer is in module > java.base of loader 'bootstrap')\n\tat > java.base/com.sun.crypto.provider.GaloisCounterMode$GCMEngine.overlapDetection(GaloisCounterMode.java:865)\n\tat > > java.base/com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt.doFinal(GaloisCounterMode.java:1502)\n\tat > > java.base/com.sun.crypto.provider.GaloisCounterMode.engineDoFinal(GaloisCounterMode.java:447)\n\tat > > {code} > -The issue is exposed with JDK 17, trunk; if interested, ping- [~e.dimitrova] > -for current branch as there is no feature branch at the moment- we can > build and start from trunk with JDK17 already. Circle CI can be run for JDK17 > too. For more information how to do that - .circleci/readme.md > CC [~benedict] -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org