Specialize JournalSegment to specified StorageLevel
Description
atomix-storage's JournalSegment is shared for all storage levels, but has special case handling from StorageLevel.MAPPED. Furthermore initial segment read (for indexing purposes) always uses StorageLevel.DISK-based logic.
on instantiation (i.e. loadSegment()-time), the file is read to populate index and establish the last written entry
if StorageLevel.MAPPED is used, then we have a MappedByteBuffer attached to the writer
JournalSegment dances around the writer implementation, switching back and forth, i.e. at idle it uses FileChannel writer – presumably to reduce MappedByteBuffer overhead – but that ends up costing us heap due to FileChannelJournalSegment.memory
We need to specialize JournalSegment, so that the MappedJournalSegment manages the MappedBuffer separately from the writer – allowing the readers to be managed separately from the writer – hence allowing JournalSegmentWriter.close() do the same thing JournalSegmentReader.close().
High
atomix-storage's JournalSegment is shared for all storage levels, but has special case handling from StorageLevel.MAPPED. Furthermore initial segment read (for indexing purposes) always uses StorageLevel.DISK-based logic.
With https://lf-opendaylight.atlassian.net/browse/CONTROLLER-2043#icft=CONTROLLER-2043, CONTROLLER-2096 and CONTROLLER-2098 it is clear that there are four things that are happening:
JournalSegment owns the FileChannel
on instantiation (i.e. loadSegment()-time), the file is read to populate index and establish the last written entry
if StorageLevel.MAPPED is used, then we have a MappedByteBuffer attached to the writer
JournalSegment dances around the writer implementation, switching back and forth, i.e. at idle it uses FileChannel writer – presumably to reduce MappedByteBuffer overhead – but that ends up costing us heap due to FileChannelJournalSegment.memory
We need to specialize JournalSegment, so that the MappedJournalSegment manages the MappedBuffer separately from the writer – allowing the readers to be managed separately from the writer – hence allowing JournalSegmentWriter.close() do the same thing JournalSegmentReader.close().