-
Bug
-
Resolution: Fixed
-
P3
-
16
-
openjdk version "16-ea" 2021-03-16
OpenJDK Runtime Environment (build 16-ea+30-2130)
OpenJDK 64-Bit Server VM (build 16-ea+30-2130, mixed mode, sharing)
-
b32
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8259599 | 17 | Maurizio Cimadamore | P3 | Resolved | Fixed | b05 |
JDK-8260123 | 16.0.1 | Maurizio Cimadamore | P3 | Resolved | Fixed | b03 |
- Windows behaviour (can't delete files when open,..)
- Disable fsync to make the Lucene developer's SSD survive longer
- track open file handles
Unfortunetely while implementing a replacement for MappedByteBuffer usage in MMapDirectory using project Panama's MemorySegments, we discovered, that the following happens, if you try to mmap a file from a file system that returns a custom FileChannel implementation (although it only wraps everything from its public API):
org.apache.lucene.store.TestMultiMMap > testFileExistsInListAfterCreated FAILED
java.lang.ClassCastException: class org.apache.lucene.mockfile.HandleTrackingFS$3 cannot be cast to class sun.nio.ch.FileChannelImpl (org.apache.lucene.mockfile.HandleTrackingFS$3 is in unnamed module of loader 'app'; sun.nio.ch.FileChannelImpl is in module java.base of loader 'bootstrap')
at __randomizedtesting.SeedInfo.seed([32623CC06FD28A36:98BBD11AF9EC8385]:0)
at jdk.incubator.foreign/jdk.internal.foreign.MappedMemorySegmentImpl.makeMappedSegment(MappedMemorySegmentImpl.java:117)
at jdk.incubator.foreign/jdk.incubator.foreign.MemorySegment.mapFile(MemorySegment.java:890)
at org.apache.lucene.store.MMapDirectory.map(MMapDirectory.java:256)
at org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:227)
There should be a way to do the same without casting the file channel to some internal implementation class, because this makes wrapping impossible.
Before Panama goes into JDK's core this must really be solved:
Add the missing hooks for mapping files to memory segments to the public FileSystem API / FileChannel interface!
IMHO, the code should be moved to the public FileChannel API, maybe using a default implementation in FileChannel interface that by default only throws UOE. Only FileChannelImpl implements the Mapping/Unmapper code, but this would avoid the ClassCastException and it would be possible for implementors of Custom FileSystems to implement the behavious or delegate to the FileChannel behind.
- backported by
-
JDK-8259599 ClassCastException when using custom filesystem with wrapper FileChannel impl
-
- Resolved
-
-
JDK-8260123 ClassCastException when using custom filesystem with wrapper FileChannel impl
-
- Resolved
-
- csr for
-
JDK-8259321 ClassCastException when using custom filesystem with wrapper FileChannel impl
-
- Closed
-
- relates to
-
JDK-8281412 MemorySegment::map should live in FileChannel
-
- Resolved
-
-
JDK-8259034 PANAMA: MemorySegment#mapFile should alternatively take FileChannel instead of Path
-
- Closed
-