hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zhe Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HDFS-8964) Provide max TxId when validating in-progress edit log files
Date Tue, 01 Sep 2015 07:53:46 GMT

     [ https://issues.apache.org/jira/browse/HDFS-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Zhe Zhang updated HDFS-8964:
----------------------------
    Attachment: HDFS-8964.04.patch

All reported failures pass locally. Updating the patch to fix checkstyle and whitespace issues.

The added test is causing the following warning:
{code}
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/zhezhang/.m2/repository/org/slf4j/slf4j-log4j12/1.7.10/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/zhezhang/.m2/repository/ch/qos/logback/logback-classic/1.1.2/logback-classic-1.1.2.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
{code}

Not sure if it's we are OK with it.

> Provide max TxId when validating in-progress edit log files
> -----------------------------------------------------------
>
>                 Key: HDFS-8964
>                 URL: https://issues.apache.org/jira/browse/HDFS-8964
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: journal-node, namenode
>    Affects Versions: 2.7.1
>            Reporter: Zhe Zhang
>            Assignee: Zhe Zhang
>         Attachments: HDFS-8964.00.patch, HDFS-8964.01.patch, HDFS-8964.02.patch, HDFS-8964.03.patch,
HDFS-8964.04.patch
>
>
> NN/JN validates in-progress edit log files in multiple scenarios, via {{EditLogFile#validateLog}}.
The method scans through the edit log file to find the last transaction ID.
> However, an in-progress edit log file could be actively written to, which creates a race
condition and causes incorrect data to be read (and later we attempt to interpret the data
as ops).
> Currently {{validateLog}} is used in 3 places:
> # NN {{getEditsFromTxid}}
> # JN {{getEditLogManifest}}
> # NN/JN {{recoverUnfinalizedSegments}}
> In the first two scenarios we should provide a maximum TxId to validate in the in-progress
file. The 3rd scenario won't cause a race condition because only non-current in-progress edit
log files are validated.
> {{validateLog}} is actually only used with in-progress files, and could use a better
name and Javadoc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message