apache/druid · error · UOE

HDFS CharSequence not supported

Error message

HDFS CharSequence not supported

What it means

Same pattern as openReader: the HDFS FileObject's getCharContent(ignoreEncodingErrors) throws UOE("HDFS CharSequence not supported") because returning the whole file content as a CharSequence is not implemented for HDFS-backed binary segment files. The method exists only to satisfy the javax.tools.FileObject interface and is intentionally unimplemented for this storage backend.

Source

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

      }

      @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 {
          final FileSystem fs = path.getFileSystem(config);
          return fs.getFileStatus(path).getModificationTime();
        }
        catch (IOException ex) {
          throw new HdfsIOException(ex);
        }

View on GitHub (pinned to 9b90983fd2)

Solutions

  1. Read via openInputStream() and materialize the CharSequence yourself from the bytes.
  2. Use a different URIDataPuller/FileObject implementation for character-content access.
  3. Guard call sites: for hdfs:// scheme URIs, never call getCharContent.

Example fix

// before
CharSequence cs = fileObject.getCharContent(false);
// after
try (InputStream in = fileObject.openInputStream()) {
  CharSequence cs = new String(ByteStreams.toByteArray(in), StandardCharsets.UTF_8);
}
Defensive patterns

Strategy: type-guard

Validate before calling

if ("hdfs".equalsIgnoreCase(uri.getScheme())) { /* do not call getCharContent */ }

Type guard

boolean supportsCharContent(FileObject fo) { return !isHdfsFileObject(fo); }

Try / catch

try { return fo.getCharContent(false); }
catch (UOE e) { return slurpInputStream(fo.openInputStream()); }

Prevention

When it happens

Trigger: Calling getCharContent on the FileObject produced by HdfsDataSegmentPuller.buildFileObject — any consumer expecting in-memory character content of an hdfs:// URI.

Common situations: Generic FileObject-based tooling that buffers file content as CharSequence; code ported from local-filesystem FileObjects to HDFS URIs without changing the content-access API.

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/e35e62a52cd7a0d1. Report an issue: GitHub.