[
https://issues.apache.org/jira/browse/HADOOP-6196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay Booth updated HADOOP-6196:
------------------------------
Attachment: sync-bug.patch
So, it turns out that SequenceFile.Writer generates its sync block and headers
statically at classloader time, so if it generates the 'right' binary data,
it'll evade this bug. I can't reproduce the bug reliably without running the
test multiple times in a row by hand, unless someone knows a way to re-execute
static code in a running jvm. It occurs about 2/3 of the time or so.
Modifying SequenceFile to expose those values for writing by a test seems like
overkill... should we just leave as is? If the build runs frequently enough,
it'll catch regressions eventually, right? All the other ideas I have are
hacky.
Issues with JUnit 4 and whitespace in the patch have been addressed.
> sync(0); next() breaks SequenceFile
> -----------------------------------
>
> Key: HADOOP-6196
> URL: https://issues.apache.org/jira/browse/HADOOP-6196
> Project: Hadoop Common
> Issue Type: Bug
> Reporter: Jay Booth
> Attachments: sync-bug.patch
>
>
> Currently, the end of the SequenceFile header is a sync block that isn't
> prefaced with SYNC_ESCAPE. This means that sync(0) followed by next() fails.
> Patch w/ test attached, bumps VERSION from 6 to 7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
