[jira] [Updated] (HDFS-13133) Ozone: OzoneFileSystem: Calling delete with non-existing path shouldn't be logged on ERROR level
[ https://issues.apache.org/jira/browse/HDFS-13133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mukul Kumar Singh updated HDFS-13133: - Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the contribution [~elek], I have committed this to the feature branch. > Ozone: OzoneFileSystem: Calling delete with non-existing path shouldn't be > logged on ERROR level > > > Key: HDFS-13133 > URL: https://issues.apache.org/jira/browse/HDFS-13133 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone >Affects Versions: HDFS-7240 >Reporter: Elek, Marton >Assignee: Elek, Marton >Priority: Major > Fix For: HDFS-7240 > > Attachments: HDFS-13133-HDFS-7240.001.patch > > > During the test of OzoneFileSystem with spark I noticed ERROR messages > multiple times: > Something like this: > {code} > 2018-02-11 15:54:54 ERROR OzoneFileSystem:409 - Couldn't delete > o3://bucket1.test/user/hadoop/.sparkStaging/application_1518349702045_0008 - > does not exist > {code} > I checked the other implemetations, and they use DEBUG level. I think it's > expected that the path sometimes points to a non-existing dir/file. > To be consistent with the other implemetation I propose to lower the log > level to debug. > Examples from other file systems: > S3AFileSystem: > {code} > } catch (FileNotFoundException e) { > LOG.debug("Couldn't delete {} - does not exist", f); > instrumentation.errorIgnored(); > return false; > } catch (AmazonClientException e) { > throw translateException("delete", f, e); > } > {code} > Alyun: > {code} >try { > return innerDelete(getFileStatus(path), recursive); > } catch (FileNotFoundException e) { > LOG.debug("Couldn't delete {} - does not exist", path); > return false; > } > {code} > SFTP: > {code} >} catch (FileNotFoundException e) { > // file not found, no need to delete, return true > return false; > } > {code} > SwiftNativeFileSystem: > {code} > try { > return store.delete(path, recursive); > } catch (FileNotFoundException e) { > //base path was not found. > return false; > } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-13133) Ozone: OzoneFileSystem: Calling delete with non-existing path shouldn't be logged on ERROR level
[ https://issues.apache.org/jira/browse/HDFS-13133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elek, Marton updated HDFS-13133: Status: Patch Available (was: Open) > Ozone: OzoneFileSystem: Calling delete with non-existing path shouldn't be > logged on ERROR level > > > Key: HDFS-13133 > URL: https://issues.apache.org/jira/browse/HDFS-13133 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone >Affects Versions: HDFS-7240 >Reporter: Elek, Marton >Assignee: Elek, Marton >Priority: Major > Fix For: HDFS-7240 > > Attachments: HDFS-13133-HDFS-7240.001.patch > > > During the test of OzoneFileSystem with spark I noticed ERROR messages > multiple times: > Something like this: > {code} > 2018-02-11 15:54:54 ERROR OzoneFileSystem:409 - Couldn't delete > o3://bucket1.test/user/hadoop/.sparkStaging/application_1518349702045_0008 - > does not exist > {code} > I checked the other implemetations, and they use DEBUG level. I think it's > expected that the path sometimes points to a non-existing dir/file. > To be consistent with the other implemetation I propose to lower the log > level to debug. > Examples from other file systems: > S3AFileSystem: > {code} > } catch (FileNotFoundException e) { > LOG.debug("Couldn't delete {} - does not exist", f); > instrumentation.errorIgnored(); > return false; > } catch (AmazonClientException e) { > throw translateException("delete", f, e); > } > {code} > Alyun: > {code} >try { > return innerDelete(getFileStatus(path), recursive); > } catch (FileNotFoundException e) { > LOG.debug("Couldn't delete {} - does not exist", path); > return false; > } > {code} > SFTP: > {code} >} catch (FileNotFoundException e) { > // file not found, no need to delete, return true > return false; > } > {code} > SwiftNativeFileSystem: > {code} > try { > return store.delete(path, recursive); > } catch (FileNotFoundException e) { > //base path was not found. > return false; > } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org
[jira] [Updated] (HDFS-13133) Ozone: OzoneFileSystem: Calling delete with non-existing path shouldn't be logged on ERROR level
[ https://issues.apache.org/jira/browse/HDFS-13133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elek, Marton updated HDFS-13133: Summary: Ozone: OzoneFileSystem: Calling delete with non-existing path shouldn't be logged on ERROR level (was: Ozone: OzoneFileSystem: Calling delete with non-exsistent path shouldn't cause ERROR log message) > Ozone: OzoneFileSystem: Calling delete with non-existing path shouldn't be > logged on ERROR level > > > Key: HDFS-13133 > URL: https://issues.apache.org/jira/browse/HDFS-13133 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: ozone >Affects Versions: HDFS-7240 >Reporter: Elek, Marton >Assignee: Elek, Marton >Priority: Major > Fix For: HDFS-7240 > > Attachments: HDFS-13133-HDFS-7240.001.patch > > > During the test of OzoneFileSystem with spark I noticed ERROR messages > multiple times: > Something like this: > {code} > 2018-02-11 15:54:54 ERROR OzoneFileSystem:409 - Couldn't delete > o3://bucket1.test/user/hadoop/.sparkStaging/application_1518349702045_0008 - > does not exist > {code} > I checked the other implemetations, and they use DEBUG level. I think it's > expected that the path sometimes points to a non-existing dir/file. > To be consistent with the other implemetation I propose to lower the log > level to debug. > Examples from other file systems: > S3AFileSystem: > {code} > } catch (FileNotFoundException e) { > LOG.debug("Couldn't delete {} - does not exist", f); > instrumentation.errorIgnored(); > return false; > } catch (AmazonClientException e) { > throw translateException("delete", f, e); > } > {code} > Alyun: > {code} >try { > return innerDelete(getFileStatus(path), recursive); > } catch (FileNotFoundException e) { > LOG.debug("Couldn't delete {} - does not exist", path); > return false; > } > {code} > SFTP: > {code} >} catch (FileNotFoundException e) { > // file not found, no need to delete, return true > return false; > } > {code} > SwiftNativeFileSystem: > {code} > try { > return store.delete(path, recursive); > } catch (FileNotFoundException e) { > //base path was not found. > return false; > } > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org