[ https://issues.apache.org/jira/browse/HADOOP-17948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Nauroth resolved HADOOP-17948. ------------------------------------ Resolution: Duplicate I'm closing this as a duplicate of YARN-3606. I don't expect there will be changes made in this area, because the timestamp check has worked well for a fast and lightweight check of unexpected resource changes. YARN-3606 contains more discussion. > JAR in conflict with timestamp check causes AM errors > ----------------------------------------------------- > > Key: HADOOP-17948 > URL: https://issues.apache.org/jira/browse/HADOOP-17948 > Project: Hadoop Common > Issue Type: Bug > Components: common > Affects Versions: 2.9.2 > Reporter: Michael Taylor > Priority: Blocker > > After an init action pulls down a new JAR and the check of a JAR's timestamp > is performed [1]we can sometimes cause an incorrect error if the timestamp > does not match. In order to address this you can perform workarounds like: > record old timestamp at the beginning before the connector is changed > local -r old_file_time=$(date -r ${dataproc_common_lib_dir}/gcs-connector.jar > "+%m%d%H%M.00") > # at end of script. > touch -t "${old_file_time}" <any jar they changed> > touch -h -t "${old_file_time}" <symlinks they changed> > We should instead of checking the date be comparing version compatibility > tests. > > > 1. > https://github.com/apache/hadoop/blob/release-2.7.3-RC2/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common/src/main/java/org/apache/hadoop/yarn/util/FSDownload.java#L255-L258 -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-issues-h...@hadoop.apache.org