[
https://issues.apache.org/jira/browse/ZOOKEEPER-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13956044#comment-13956044
]
Michi Mutsuzaki commented on ZOOKEEPER-1520:
--------------------------------------------
Sorry for jumping in this late, but to answer Flavio's question:
{quote}
Also, the sentinel being zero does not necessarily mean that there has been no
corruption. I understand that it is a pretty good guess, though, because of the
zeroing during preallocation. If it happens that there has been a corruption
and we simply considered it as a partial record. Is it acceptable to have such
a low probability corner case? I'm just pointing this out because the behavior
wouldn't be consistent if we hit this case.
{quote}
I think we can check if the record is corrupted by validating the checksum,
using 0x42 as the last byte instead of 0x0. By the way, it's kind of strange
that readTxnBytes() doesn't validate the checksum at all.
> A txn log record with a corrupt sentinel byte looks like EOF
> ------------------------------------------------------------
>
> Key: ZOOKEEPER-1520
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1520
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.3.5
> Environment: all
> Reporter: Bill Bridge
> Assignee: Bill Bridge
> Priority: Minor
> Labels: newbie, patch
> Fix For: 3.4.7, 3.5.0
>
> Attachments: ZOOKEEPER-1520.patch, ant.out, checkout.out, init.out,
> init.out
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> In Util.readTxnBytes() the sentinel is compared with 0x42 and if it does not
> match then the record is considered partially written and thus the EOF.
> However if it is a partial record the sentinel should be 0x00 since that is
> what the log is initialized with. Any other value would indicate corruption
> and should throw an IOException rather than indicate EOF. See
> [ZOOKEEPER-1453|https://issues.apache.org/jira/browse/ZOOKEEPER-1453] for a
> related issue.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
