[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17730281#comment-17730281
]
dan jatnieks edited comment on CASSANDRA-18180 at 6/7/23 9:20 PM:
------------------------------------------------------------------
I think that's a good suggestion. So the idea I have for that is to add a class
like:
{noformat}
DirectBufferRef<T extends DirectBuffer> extends Ref<T> implements DirectBuffer
{noformat}
This can use used in {{BufferPool.setAttachment}} , like so:
{noformat}
MemoryUtil.setAttachment(buffer, new DirectBufferRef<>(this, null));
{noformat}
Here's a patch with that approach; let me know if it matches the suggestion or
I could try something else: [^cassandra-18180-directbufferref.diff]
I also noticed that {{MerkleTree}} has some similar code that sets a {{Ref}} as
a {{ByteBuffer}} attachment, and in fact, I think any caller of
{{MemoryUtil.setAttachment}} probably needs to ensure that the attachment
object implements {{DirectBuffer}} in case it gets used with encryption enabled.
The {{MerkleTree}} case is a bit easier than {{BufferPool}} because it only
uses a {{null}} referent, so it's enough just to use something like the
{{DirectBufferRef}} mentioned above (no need to implement {{DirectBuffer}} in
{{MerkleTree}} afaict). [This is not included yet in the patch]
I thought that perhaps it would be a good idea to even enforce it in
{{{}MemoryUtil{}}}, something like:
{noformat}
public static <T extends DirectBuffer> void setAttachment(ByteBuffer
instance, T next)
{noformat}
However, then I found that {{SyncUtil.force}} uses {{MemoryUtil.getAttachment}}
and expects that the attachment may be {{{}Runnable{}}}. I'm not sure yet how
that gets set though - I didn't any other {{setAttachment}} calls with
{{Runnable}} except in a unit test. Right now I'm not sure what to do about
this one - and I'm concerned that when encryption is being used, this could
again lead to a {{{}ClassCastException{}}}.
was (Author: djatnieks):
I think that's a good suggestion. So the idea I have for that is to add a class
like:
{noformat}
DirectBufferRef<T extends DirectBuffer> extends Ref<T> implements DirectBuffer
{noformat}
This can use used in {{BufferPool.setAttachment}} , like so:
{noformat}
MemoryUtil.setAttachment(buffer, new DirectBufferRef<>(this, null));
{noformat}
Here's a patch with that approach; let me know if it matches the suggestion or
I could try something else: [^cassandra-18180-directbufferref.diff]
I also noticed that {{MerkleTree}} has some similar code that sets a {{Ref}} as
a {{ByteBuffer}} attachment, and in fact, I think any caller of
{{MemoryUtil.setAttachment}} probably needs to ensure that the attachment
object implements {{DirectBuffer}} in case it gets used with encryption enabled.
The {{MerkleTree}} case is a bit easier than {{BufferPool}} because it only
uses a {{null}} referent, so it's enough just to use something like the
{{DirectBufferRef}} mentioned above (no need to implement {{DirectBuffer}} in
{{MerkleTree}} afaict).
I thought that perhaps it would be a good idea to even enforce it in
{{{}MemoryUtil{}}}, something like:
{noformat}
public static <T extends DirectBuffer> void setAttachment(ByteBuffer
instance, T next)
{noformat}
However, then I found that {{SyncUtil.force}} uses {{MemoryUtil.getAttachment}}
and expects that the attachment may be {{{}Runnable{}}}. I'm not sure yet how
that gets set though - I didn't any other {{setAttachment}} calls with
{{Runnable}} except in a unit test. Right now I'm not sure what to do about
this one - and I'm concerned that when encryption is being used, this could
again lead to a {{{}ClassCastException{}}}.
> 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
> Fix For: 5.x
>
> Attachments: cassandra-18180-directbufferref.diff
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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]
