What causes "${className} does not support release buffer." in apache/hadoop?

Only call releaseBuffer() for buffers actually returned by read(ByteBufferPool,...) on the same stream

apache/hadoop · error · UnsupportedOperationException

${className} does not support release buffer.

Error message

${className} does not support release buffer.

What it means

releaseBuffer(ByteBuffer) returns pooled buffers to the wrapped stream, so it requires `in instanceof HasEnhancedByteBufferAccess` — the same interface that governs obtaining such buffers. If the inner stream lacks it, UnsupportedOperationException naming the wrapped class is thrown.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/CryptoInputStream.java:741

          + " does not support enhanced byte buffer access.");
    }
    final ByteBuffer buffer = ((HasEnhancedByteBufferAccess) in).
        read(bufferPool, maxLength, opts);
    if (buffer != null) {
      final int n = buffer.remaining();
      if (n > 0) {
        streamOffset += buffer.remaining(); // Read n bytes
        final int pos = buffer.position();
        decrypt(buffer, n, pos);
      }
    }
    return buffer;
  }

  @Override
  public void releaseBuffer(ByteBuffer buffer) {
    if (!(in instanceof HasEnhancedByteBufferAccess)) {
      throw new UnsupportedOperationException(in.getClass().getCanonicalName()
          + " does not support release buffer.");
    }
    ((HasEnhancedByteBufferAccess) in).releaseBuffer(buffer);
  }

  @Override
  public void setReadahead(Long readahead) throws IOException,
      UnsupportedOperationException {
    if (!(in instanceof CanSetReadahead)) {
      throw new UnsupportedOperationException(in.getClass().getCanonicalName()
          + " does not support setting the readahead caching strategy.");
    }
    ((CanSetReadahead) in).setReadahead(readahead);
  }

  @Override
  public void setDropBehind(Boolean dropCache) throws IOException,
      UnsupportedOperationException {

View on GitHub (pinned to 2add963021)

Solutions

Only call releaseBuffer() for buffers actually returned by read(ByteBufferPool,...) on the same stream
Track the acquisition path (pooled vs byte[]) so the release path matches it
Catch UnsupportedOperationException in cleanup code so release failures never mask the primary result

Example fix

// before
if (buffer != null) {
  cryptoIn.releaseBuffer(buffer); // UOE if pooled reads unsupported
}

// after
if (buffer != null) {
  try {
    cryptoIn.releaseBuffer(buffer);
  } catch (UnsupportedOperationException e) {
    // pooled path never active on this stream; nothing to return
  }
}

Defensive patterns

Strategy: try-catch

Try / catch

try {
  in.releaseBuffer(buffer);
} catch (UnsupportedOperationException e) {
  // pooled path was never active on this stream; nothing to return
}

Prevention

Track whether each buffer came from the pooled API before releasing it
Keep acquisition and release code paths symmetric
Never let cleanup-time release failures mask the primary read result

When it happens

Trigger: Calling releaseBuffer() on a CryptoInputStream that never handed out pooled buffers (inner stream lacks HasEnhancedByteBufferAccess); cleanup paths that release unconditionally after a read fell back to plain byte[] reads.

Common situations: Zero-copy readers whose buffer-release code does not track whether the acquisition actually succeeded through the pooled path.

Related errors

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