apache/hadoop · error · IOException

no such method

Error message

no such method

What it means

callCOSClientWithRetry dispatches on the concrete request type via instanceof chains (UploadPartRequest, DeleteObjectRequest, CopyObjectRequest, GetObjectRequest, ListObjectsRequest, ...). Any request object that is not one of the recognized types falls into the final else branch and throws IOException("no such method") with no retry and no SDK call. This is a programming/versioning defect inside the connector or its callers, not a backend condition.

Source

Thrown at hadoop-cloud-storage-project/hadoop-cos/src/main/java/org/apache/hadoop/fs/cosn/CosNativeFileSystemStore.java:716

        } else if (request instanceof GetObjectMetadataRequest) {
          sdkMethod = "queryObjectMeta";
          return this.cosClient.getObjectMetadata(
              (GetObjectMetadataRequest) request);
        } else if (request instanceof DeleteObjectRequest) {
          sdkMethod = "deleteObject";
          this.cosClient.deleteObject((DeleteObjectRequest) request);
          return new Object();
        } else if (request instanceof CopyObjectRequest) {
          sdkMethod = "copyFile";
          return this.cosClient.copyObject((CopyObjectRequest) request);
        } else if (request instanceof GetObjectRequest) {
          sdkMethod = "getObject";
          return this.cosClient.getObject((GetObjectRequest) request);
        } else if (request instanceof ListObjectsRequest) {
          sdkMethod = "listObjects";
          return this.cosClient.listObjects((ListObjectsRequest) request);
        } else {
          throw new IOException("no such method");
        }
      } catch (CosServiceException cse) {
        String errMsg = String.format("Call cos sdk failed, "
                + "retryIndex: [%d / %d], "
                + "call method: %s, exception: %s",
            retryIndex, this.maxRetryTimes, sdkMethod, cse.toString());
        int statusCode = cse.getStatusCode();
        // Retry all server errors
        if (statusCode / 100 == 5) {
          if (retryIndex <= this.maxRetryTimes) {
            LOG.info(errMsg);
            long sleepLeast = retryIndex * 300L;
            long sleepBound = retryIndex * 500L;
            try {
              if (request instanceof UploadPartRequest) {
                if (((UploadPartRequest) request).getInputStream()
                    instanceof ByteBufferInputStream) {
                  ((UploadPartRequest) request).getInputStream().reset();

View on GitHub (pinned to 2add963021)

Solutions

1. Do not call callCOSClientWithRetry directly — use the public store/filesystem APIs, which construct only supported request types
2. Align the qcloud cos_api sdk version with the one the hadoop-cos release declares in its pom
3. If you maintain a fork, extend the instanceof dispatch chain to cover the new request type and send the mapping upstream

// Don't reach the dispatch at all: only pass the request types it explicitly handles
private static final Set<Class<?>> SUPPORTED = new HashSet<>(Arrays.asList(
    PutObjectRequest.class, UploadPartRequest.class, DeleteObjectRequest.class,
    CopyObjectRequest.class, GetObjectRequest.class, ListObjectsRequest.class));
if (!SUPPORTED.contains(request.getClass())) {
  throw new IllegalArgumentException("Unsupported request type: " + request.getClass());
}

boolean isDispatchableRequest(Object r) {
  return r instanceof PutObjectRequest || r instanceof UploadPartRequest
      || r instanceof DeleteObjectRequest || r instanceof CopyObjectRequest
      || r instanceof GetObjectRequest || r instanceof ListObjectsRequest;
}

When it happens

Trigger: Passing a request type the dispatch chain does not cover — e.g. a newly added COS SDK request class, a custom subclass of a known request, or calling the package-private retry helper directly with an unsupported request. Can also appear after mixing hadoop-cos jar versions with a qcloud cos_api sdk version that introduced new request types.

Common situations: Shading/classpath conflicts producing mismatched hadoop-cos + cos_api versions; custom code inside the org.apache.hadoop.fs.cosn package calling callCOSClientWithRetry; upgrading the COS SDK without upgrading the connector.

Related errors

• dump not supported
• %s : %s
• Call cos sdk failed, call method: %s, exception: %s
• No COS Credential Providers
• Credentials requested after provider list was closed

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