apache/hadoop · error · IOException

Not yet implemented.

Error message

Not yet implemented.

What it means

TaskAttemptListenerImpl is the MR ApplicationMaster's implementation of the TaskUmbilicalProtocol that child task JVMs call. reportNextRecordRange is intentionally unimplemented: in MRv2 the next-record-range information travels inside statusUpdate, so a well-matched child never invokes this method. If something does call it -- an old or version-mismatched task runtime using the legacy skip-records flow, or custom code talking to the umbilical directly -- it receives IOException('Not yet implemented.') and the task attempt fails.

Source

Thrown at hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app/src/main/java/org/apache/hadoop/mapred/TaskAttemptListenerImpl.java:512

    coalesceStatusUpdate(yarnAttemptID, taskAttemptStatus, lastStatusRef);

    return feedback;
  }

  @Override
  public long getProtocolVersion(String arg0, long arg1) throws IOException {
    return TaskUmbilicalProtocol.versionID;
  }

  @Override
  public void reportNextRecordRange(TaskAttemptID taskAttemptID, Range range)
      throws IOException {
    // This is used when the feature of skipping records is enabled.

    // This call exists as a hadoop mapreduce legacy wherein all changes in
    // counters/progress/phase/output-size are reported through statusUpdate()
    // call but not the next record range information.
    throw new IOException("Not yet implemented.");
  }

  @Override
  public JvmTask getTask(JvmContext context) throws IOException {

    // A rough imitation of code from TaskTracker.

    JVMId jvmId = context.jvmId;
    LOG.info("JVM with ID : {} asked for a task", jvmId);

    JvmTask jvmTask = null;
    // TODO: Is it an authorized container to get a task? Otherwise return null.

    // TODO: Child.java's firstTaskID isn't really firstTaskID. Ask for update
    // to jobId and task-type.

    WrappedJvmID wJvmID = new WrappedJvmID(jvmId.getJobId(), jvmId.isMap,
        jvmId.getId());

View on GitHub (pinned to 2add963021)

Solutions

1. Align the Hadoop mapreduce-client version used by the job's jars with the cluster (drop old hadoop-* jars from the job's lib; use provided scope)
2. Do not call umbilical.reportNextRecordRange; report the range via statusUpdate / TaskReport as MRv2 tasks do
3. Remove legacy skip-mode settings from the job config if they come from Hadoop-1-era templates (mapreduce.task.skip.*)

Example fix

// before: legacy/direct call
umbilical.reportNextRecordRange(attemptId, range);
// after: let the standard task reporter convey range via statusUpdate
umbilical.statusUpdate(taskAttemptId, taskStatus);

Catch IOException from umbilical calls in custom task runtimes and fall back to statusUpdate-based reporting; treat 'Not yet implemented.' as a protocol-contract violation to fix in code, not a transient error to retry.

When it happens

Trigger: Submitting a job with old Hadoop-1-era mapreduce client jars on the classpath while the AM runs Hadoop 2/3; custom Task implementations or test harnesses invoking umbilical.reportNextRecordRange directly; enabling legacy record-skip settings with mismatched runtimes.

Common situations: Mixed-version clusters after an upgrade (old task jars in the user's lib directory); third-party frameworks that reuse TaskUmbilicalProtocol; unit tests stubbing the protocol calling this method.

Related errors

• "Not creating intermediate history logDir: [" + doneDirPath
• Unrecognized task type: {}
• Unrecognized State: {}
• Unrecognized Phase: {}
• Unrecognized status: {}

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