What causes "HDFS Reader not supported" in apache/druid?

Use openInputStream() and read the bytes yourself, decoding to text explicitly if the content is character data.

apache/druid · error · UOE

HDFS Reader not supported

Error message

HDFS Reader not supported

What it means

The anonymous FileObject returned by HdfsDataSegmentPuller.buildFileObject only implements stream-based access (openInputStream/openOutputStream); openReader deliberately throws UOE("HDFS Reader not supported") because HDFS segments are binary and the javax.tools.FileObject character-reader contract has no meaningful HDFS implementation. Calling openReader on this FileObject always throws; it is an unconditional unsupported-operation signal, not a data-dependent failure.

Source

Thrown at extensions-core/hdfs-storage/src/main/java/org/apache/druid/storage/hdfs/HdfsDataSegmentPuller.java:140

      @Override
      public InputStream openInputStream() throws IOException
      {
        final FileSystem fs = path.getFileSystem(config);
        return fs.open(path);
      }

      @Override
      public OutputStream openOutputStream() throws IOException
      {
        final FileSystem fs = path.getFileSystem(config);
        return fs.create(path, overwrite);
      }

      @Override
      public Reader openReader(boolean ignoreEncodingErrors)
      {
        throw new UOE("HDFS Reader not supported");
      }

      @Override
      public CharSequence getCharContent(boolean ignoreEncodingErrors)
      {
        throw new UOE("HDFS CharSequence not supported");
      }

      @Override
      public Writer openWriter()
      {
        throw new UOE("HDFS Writer not supported");
      }

      @Override
      public long getLastModified()
      {
        try {

View on GitHub (pinned to 9b90983fd2)

Solutions

Use openInputStream() and read the bytes yourself, decoding to text explicitly if the content is character data.
Route text-file reads to a scheme-appropriate puller (e.g. a local or HTTP puller) instead of the HDFS one.
If you control the calling code, branch on URI scheme before choosing a Reader-based API and fall back to InputStream for hdfs://.

Example fix

// before
Reader r = fileObject.openReader(true);
// after
try (InputStream in = fileObject.openInputStream()) {
  String text = new String(ByteStreams.toByteArray(in), StandardCharsets.UTF_8);
}

Defensive patterns

Strategy: type-guard

Validate before calling

if (!uri.getScheme().equalsIgnoreCase("hdfs")) { useNonHdfsReader(uri); }

Type guard

boolean supportsReader(FileObject fo) { return !(fo.getClass().getName().startsWith("org.apache.druid.storage.hdfs")); }

Try / catch

try { return fo.openReader(true); }
catch (UOE e) { return readViaInputStream(fo); }

Prevention

Never use Reader/CharSequence FileObject APIs against hdfs:// URIs.
Wrap HDFS access in helpers that expose only InputStream-based reads.
Document the HDFS FileObject's supported surface (openInputStream/openOutputStream/getLastModified/delete only).

When it happens

Trigger: Any code path that obtains the FileObject from buildFileObject(uri, config) and invokes openReader(ignoreEncodingErrors) — e.g. tooling that treats deep-storage URIs as text FileObjects, or generic compiler/FileObject consumers.

Common situations: Custom tooling or third-party code treating hdfs:// URIs as character sources; frameworks that enumerate FileObject methods for metadata or text inspection of segment descriptors.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/7bb99f11acdb4c7c. Report an issue: GitHub.