steveloughran commented on a change in pull request #2399:
URL: https://github.com/apache/hadoop/pull/2399#discussion_r522947215
##########
File path:
hadoop-common-project/hadoop-common/src/main/resources/core-default.xml
##########
@@ -1925,20 +1925,13 @@
</property>
<property>
- <name>fs.s3a.committer.staging.abort.pending.uploads</name>
+ <name>fs.s3a.committer.abort.pending.uploads</name>
<value>true</value>
<description>
- Should the staging committers abort all pending uploads to the destination
+ Should the committers abort all pending uploads to the destination
directory?
- Changing this if more than one partitioned committer is
- writing to the same destination tree simultaneously; otherwise
- the first job to complete will cancel all outstanding uploads from the
- others. However, it may lead to leaked outstanding uploads from failed
- tasks. If disabled, configure the bucket lifecycle to remove uploads
- after a time period, and/or set up a workflow to explicitly delete
- entries. Otherwise there is a risk that uncommitted uploads may run up
- bills.
+ Set to false if more than one job is writing to the same directory tree.
Review comment:
taskAbort, yet. JobAbort/cleanup is where things are more trouble,
because the job doesn't know what specific task attempts have uploaded.
with the staging committer, there's no files uploaded until task commit.
Tasks which fail before that moment don't have any pending uploads to cancel.
with the magic committer, because the files are written direct to S3, there
is more risk of pending uploads collecting.
I'm not sure about spark here, but on MR when a task is considered to have
failed, abortTask is called in the AM to abort that specific task; for the
magic committer the task's set of .pending files is determined by listing the
task attempt dir, and those operations cancelled. If that operation is called
reliably, only the current upload is pending.
Of course, if an entire job fails: no cleanup at all.
The best thing to do is simply to tell everyone to have a scheduled cleanup.
FWIW, the most leakage I see in the real world is actually from incomplete
S3ABlockOutputStream writes as again, they accrue bills. Everyone needs a
lifecycle rule to delete old ones. The sole exception there is one which our QE
team used which (unknown to them) I'd use for testing the scalability of the
"hadoop s3guard uploads" command -how well does it work when there are many,
many incomplete uploads, can it still delete them all etc. If they had a rule
then it'd screw up my test runs.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
