[ 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: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org