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

  1. 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
  2. Avoid shutting down the shared ExecutorService used for uploads before all output streams are closed
  3. 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
  4. 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

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


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/dd43f023bb09c64a. Report an issue: GitHub.