apache/hadoop · critical · IOException
Failed to multipart upload to oss, abort it.
Error message
Failed to multipart upload to oss, abort it.
What it means
Thrown at the end of AliyunOSSBlockOutputStream.close() during a multipart upload. waitForAllPartUploads() returns null only when the waiting thread was interrupted (the catch of InterruptedException re-interrupts and returns null), so this IOException means the multipart upload could not be completed because part-upload futures were abandoned, and the object was not assembled.
Source
Thrown at hadoop-tools/hadoop-aliyun/src/main/java/org/apache/hadoop/fs/aliyun/oss/AliyunOSSBlockOutputStream.java:152
// zero size file
store.storeEmptyFile(key);
} else {
OSSDataBlocks.BlockUploadData uploadData = dataBlock.startUpload();
if (uploadData.hasFile()) {
store.uploadObject(key, uploadData.getFile());
} else {
store.uploadObject(key,
uploadData.getUploadStream(), dataBlock.dataSize());
}
}
} else {
if (blockWritten > 0) {
uploadCurrentBlock();
}
// wait for the partial uploads to finish
final List<PartETag> partETags = waitForAllPartUploads();
if (null == partETags) {
throw new IOException("Failed to multipart upload to oss, abort it.");
}
store.completeMultipartUpload(key, uploadId,
new ArrayList<>(partETags));
}
} finally {
cleanupWithLogger(LOG, getActiveBlock(), blockFactory);
closed.set(true);
}
}
@Override
public synchronized void write(int b) throws IOException {
singleByte[0] = (byte)b;
write(singleByte, 0, 1);
}
@Override
public synchronized void write(byte[] b, int off, int len)View on GitHub (pinned to 2add963021)
Solutions
- Check for and log Thread.interrupted status and task-kill signals; if the task was deliberately killed, expect this failure and let the framework's task retry produce the output
- Avoid shutting down the shared ExecutorService used for uploads before all output streams are closed
- Retry the failing job/stage: since the multipart upload never completed, the destination object is absent or partial, so a clean re-run is safe
- If interrupts are unexpected, look for over-aggressive watchdogs or future.cancel(true) in your code touching the upload futures
Defensive patterns
Strategy: retry
Try / catch
catch (IOException e) { // interrupted multipart close: rely on task-level retry if (Thread.currentThread().isInterrupted()) { Thread.currentThread().interrupt(); } throw e; } Prevention
- Never shut down the shared upload ExecutorService before all output streams are closed
- Expect and allow framework task retry when tasks are killed during commit
- Keep close() on the writer thread, not a racing shutdown hook
When it happens
Trigger: The writer thread is interrupted (task kill, executor shutdownNow) while close() is waiting for part uploads of the final partial block; JVM shutdown hooks interrupt worker threads during commit; the bounded thread pool backing uploads was shut down before close() finished.
Common situations: Spark/MapReduce task cancellation racing the job committer's commitTask; executor shutdown order bugs where fs.oss.buffer.dirs upload threads are terminated first; long close() latency combined with aggressive client-side timeouts that interrupt threads.
Related errors
- Multi-part upload with id '{uploadId}' to {key}
- Credentials should not be null.
- Invalid credentials
- Stream closed.
- Append is not supported!
AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22).
Data as JSON: /api/errors/dd43f023bb09c64a.
Report an issue: GitHub.