[ https://issues.apache.org/jira/browse/HDFS-7726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tianyin Xu updated HDFS-7726: ----------------------------- Attachment: check_config_val_EditLogTailer.patch.1 > Parse and check the configuration settings of edit log to prevent runtime > errors > -------------------------------------------------------------------------------- > > Key: HDFS-7726 > URL: https://issues.apache.org/jira/browse/HDFS-7726 > Project: Hadoop HDFS > Issue Type: Bug > Components: namenode > Affects Versions: 2.6.0 > Reporter: Tianyin Xu > Priority: Minor > Attachments: check_config_val_EditLogTailer.patch.1 > > > ============================ > Problem > ------------------------------------------------- > Similar as the following two issues addressed in 2.7.0, > https://issues.apache.org/jira/browse/YARN-2165 > https://issues.apache.org/jira/browse/YARN-2166 > The edit log related configuration settings should be checked in the > constructor rather than being applied directly at runtime. This would cause > runtime failures if the values are wrong. > Take "dfs.ha.tail-edits.period" as an example, currently in > EditLogTailer.java, its value is not checked but directly used in doWork(), > as the following code snippets. Any negative values would cause > IllegalArgumentException (which is not caught) and impair the component. > {code:title=EditLogTailer.java|borderStyle=solid} > private void doWork() { > { > ..... > Thread.sleep(sleepTimeMs); > .... > } > {code} > Another example is "dfs.ha.log-roll.rpc.timeout". Right now, we use getInt() > to parse the value at runtime in the getActiveNodeProxy() function which is > called by doWork(), shown as below. Any erroneous settings (e.g., > ill-formatted integer) would cause exceptions. > {code:title=EditLogTailer.java|borderStyle=solid} > private NamenodeProtocol getActiveNodeProxy() throws IOException { > { > ..... > int rpcTimeout = conf.getInt( > DFSConfigKeys.DFS_HA_LOGROLL_RPC_TIMEOUT_KEY, > DFSConfigKeys.DFS_HA_LOGROLL_RPC_TIMEOUT_DEFAULT); > .... > } > {code} > ============================ > Solution (the attached patch) > ------------------------------------------------- > Basically, the idea of the attached patch is to move the parsing and checking > logics into the constructor to expose the error at initialization, so that > the errors won't be latent at the runtime (same as YARN-2165 and YARN-2166) > I'm not aware of the implementation of 2.7.0. It seems there's checking > utilities such as the validatePositiveNonZero function in YARN-2165. If so, > we can use that one to make the checking more systematic. -- This message was sent by Atlassian JIRA (v6.3.4#6332)