[
https://issues.apache.org/jira/browse/CASSANDRA-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901219#comment-15901219
]
Branimir Lambov commented on CASSANDRA-13282:
---------------------------------------------
Patch LGTM, but I want to make sure this isn't showing a more serious problem.
Is an upgrade involved in triggering this issue?
In 2.2+ we write the exact end of written data ({{endOfBuffer}}) on {{sync()}}
and sync sections are thus always precisely sized, thus this should not be
happening. We could end up in this situation upgrading from 2.1 and earlier,
though. Perhaps we should only ignore this if the descriptor version is pre-2.2?
> Commitlog replay may fail if last mutation is within 4 bytes of end of segment
> ------------------------------------------------------------------------------
>
> Key: CASSANDRA-13282
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13282
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jeff Jirsa
> Assignee: Jeff Jirsa
> Fix For: 2.2.x, 3.0.x, 3.11.x, 4.x
>
> Attachments: whiteboard.png
>
>
> Following CASSANDRA-9749 , stricter correctness checks on commitlog replay
> can incorrectly detect "corrupt segments" and stop commitlog replay (and
> potentially stop cassandra, depending on the configured policy). In
> {{CommitlogReplayer#replaySyncSection}} we try to read a 4 byte int
> {{serializedSize}}, and if it's 0 (which will happen due to zeroing when the
> segment was created), we continue on to the next segment. However, it appears
> that if a mutation is sized such that it ends with 1, 2, or 3 bytes remaining
> in the segment, we'll pass the {{isEOF}} on the while loop but fail to read
> the {{serializedSize}} int, and fail.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
