[
https://issues.apache.org/jira/browse/CASSANDRA-18180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17735458#comment-17735458
]
David Capwell commented on CASSANDRA-18180:
-------------------------------------------
>From [~e.dimitrova]'s 3rd point from me...
org.apache.cassandra.io.filesystem.ListenableFileSystem relies on attachment as
a way to allow the file system to implement flush when performing mmap (see
org.apache.cassandra.io.filesystem.ListenableFileSystem.ListenableFileChannel#map)
{code}
// with real files the FD gets copied so the close of the channel does not
block the BB mutation
// from flushing... it's possible to support this use case,
but kept things simplier for now by
// failing if the backing channel was closed.
Runnable forcer = () -> {
ByteBuffer local = bb.duplicate();
local.position(0);
long pos = position;
try
{
while (local.hasRemaining())
{
int wrote = write(local, pos);
if (wrote == -1)
throw new EOFException();
pos += wrote;
}
}
catch (IOException e)
{
throw new UncheckedIOException(e);
}
};
MemoryUtil.setAttachment(bb, forcer);
{code}
So, if you are making changes and
org.apache.cassandra.io.filesystem.ListenableFileSystem is working with mmap
support, then you are fine in this case... force does not require Runnable, but
allows Runnable
{code}
// org.apache.cassandra.utils.SyncUtil#force(java.nio.MappedByteBuffer)
Object attachment = MemoryUtil.getAttachment(buf);
if (attachment instanceof Runnable)
{
((Runnable) attachment).run();
return buf;
}
{code}
There are a few reasons for this
1) when doing jvm-dtest, you may have the same FileSystem shared cross multiple
instances (simulator does this), this means that the FileSystem is in app class
loader, and the users are in InstanceClassLoader... so the only type possible
are primitive JDK types
2) our force checks are hard to mock out due to the reliance of
java.nio.MappedByteBuffer#force and a FileDescriptor; 2 types that can't be
created by tests...
So yeah, the runnable is kinda a hack, but as long as you make sure its still
hitting the mmap case, then your patch doesn't break this relationship...
Simulator tests this, so if those tests are run and passing, should be fine
> 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: 40m
> 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
