[
https://issues.apache.org/jira/browse/HDFS-6038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923198#comment-13923198
]
Tsz Wo Nicholas Sze commented on HDFS-6038:
-------------------------------------------
- DataOutputBuffer.writeInt can be simplified as below.
{code}
//DataOutputBuffer.java
public void writeInt(int v, int offset) throws IOException {
int oldCount = buffer.setOffset(offset);
writeInt(v);
buffer.setOffset(oldCount);
}
{code}
- BookKeeperEditLogInputStream.scanNextOp() can be removed.
- In EditLogFileInputStream.scanEditLog, the txid variable can be declared
inside the while-loop.
- FSEditLogOp.Reader.scanOp() needs to check OP_INVALID like decodeOp().
> JournalNode hardcodes NameNodeLayoutVersion in the edit log file
> ----------------------------------------------------------------
>
> Key: HDFS-6038
> URL: https://issues.apache.org/jira/browse/HDFS-6038
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, ha, hdfs-client, namenode
> Reporter: Haohui Mai
> Assignee: Jing Zhao
> Attachments: HDFS-6038.000.patch, HDFS-6038.001.patch,
> HDFS-6038.002.patch, HDFS-6038.003.patch, HDFS-6038.004.patch, editsStored
>
>
> In HA setup, the JNs receive edit logs (blob) from the NN and write into edit
> log files. In order to write well-formed edit log files, the JNs prepend a
> header for each edit log file.
> The problem is that the JN hard-codes the version (i.e.,
> {{NameNodeLayoutVersion}} in the edit log, therefore it generates incorrect
> edit logs when the newer release bumps the {{NameNodeLayoutVersion}} during
> rolling upgrade.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
