[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17723776#comment-17723776
]
dan jatnieks edited comment on CASSANDRA-18180 at 5/18/23 3:34 PM:
-------------------------------------------------------------------
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 - this test only fails with JDK17 even though the same
{{GaloisCounterMode}} overlap detection code is present in JDK11; for some
reason the same code path is not executed and the tests pass with JDK11. 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.
was (Author: djatnieks):
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: [email protected]
For additional commands, e-mail: [email protected]
