Improve entry crc32 computation 05/110605/1
authorRobert Varga <robert.varga@pantheon.tech>
Sat, 9 Mar 2024 15:03:10 +0000 (16:03 +0100)
committerRobert Varga <robert.varga@pantheon.tech>
Mon, 11 Mar 2024 13:36:22 +0000 (14:36 +0100)
commit8d3f7dedb753b2e3e836d9004e73ee7f9f4b0e17
treebd199a5afea4e8f7b08ebc627f538c09d4e66203
parent0b6f5cce857f1f052883b5f969fac1c5ab4ca0b8
Improve entry crc32 computation

We have a codepath difference here, where we use either a ByteBuffer or
a raw array to compute CRC32.

MappedJournalSegmentWriter does not make it immediately clear we use
this buffer twice -- once for CRC32 and once for deserialization.

Move acquisition of slice just after we have read the expected CRC32, so
it is clear it is something we would be doing even if there were no
checksum involved.

Mirror the same in FileChannelJournalSegmentWriter, as this will allow
us to further consolidate the code and stop mucking with memory.limit(),
which is causing us to invalidate our previously-set mark.

JIRA: CONTROLLER-2095
Change-Id: I355bd97cd8acb4f5d9d91310de97ecb2cbd70282
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
(cherry picked from commit b8dfbae75d8e13b78d3a7d5db48de2f5e262cd87)
atomix-storage/src/main/java/io/atomix/storage/journal/FileChannelJournalSegmentWriter.java
atomix-storage/src/main/java/io/atomix/storage/journal/MappedJournalSegmentWriter.java