apache/hadoop · error · InvalidXmlException

expected </DATA>

Error message

expected </DATA>

What it means

Thrown from endElement() in HANDLE_DATA state when the stanza stack is empty (we are at <DATA> depth) and the closing tag is not </DATA>. Inside <DATA>, each child element pushes a Stanza on open and pops on close; this error means a non-DATA close tag arrived at DATA depth — in practice mis-nested or unbalanced closing tags within the DATA block.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/tools/offlineEditsViewer/OfflineEditsXmlLoader.java:221

        state = ParseState.EXPECT_END;
      } else if (!name.equals("RECORD")) {
        throw new InvalidXmlException("expected </EDITS> or </RECORD>");
      }
      break;
    case EXPECT_OPCODE:
      if (!name.equals("OPCODE")) {
        throw new InvalidXmlException("expected </OPCODE>");
      }
      opCode = FSEditLogOpCodes.valueOf(str);
      state = ParseState.EXPECT_DATA;
      break;
    case EXPECT_DATA:
      throw new InvalidXmlException("expected <DATA/>");
    case HANDLE_DATA:
      stanza.setValue(str);
      if (stanzaStack.empty()) {
        if (!name.equals("DATA")) {
          throw new InvalidXmlException("expected </DATA>");
        }
        state = ParseState.EXPECT_RECORD;
        FSEditLogOp op = opCache.get(opCode);
        opCode = null;
        try {
          op.decodeXml(stanza);
          stanza = null;
        } finally {
          if (stanza != null) {
            System.err.println("fromXml error decoding opcode " + opCode +
                "\n" + stanza.toString());
            stanza = null;
          }
        }
        if (fixTxIds) {
          if (nextTxId <= 0) {
            nextTxId = op.getTransactionId();
            if (nextTxId <= 0) {

View on GitHub (pinned to 2add963021)

Solutions

  1. Re-balance the tags inside the offending <DATA> block — every child element must be closed before </DATA>.
  2. Locate the bad block by bisecting the file (split into halves of records and re-run oev) since the message carries no line number.
  3. Restore the record from the original oev output and redo the edit with an XML-aware tool (xmllint --shell or an XML editor), not a text editor.

Example fix

// before
<DATA><NAME>foo</DATA></NAME></DATA>

// after
<DATA><NAME>foo</NAME></DATA>
Defensive patterns

Strategy: try-catch

Validate before calling

# cheap pre-check: file must be well-formed XML
xmllint --noout edits.xml && hdfs oev -i edits.xml -o out

Try / catch

try {
  loader.loadEdits();
} catch (InvalidXmlException e) {
  // mis-nested close tag inside a DATA stanza; bisect the file to find it
  LOG.error("Unbalanced DATA stanza: {}", e.getMessage());
}

Prevention

When it happens

Trigger: Mis-nested closes inside DATA such as <DATA><NAME>foo</DATA></NAME>: the first </DATA> just pops NAME off the stanza stack, then </NAME> arrives with an empty stack and name != DATA, throwing. Duplicate or extra close tags inside DATA behave the same.

Common situations: Manual edits to record payloads; sed/regex surgery on DATA contents that breaks tag balance; files whose lines were rewrapped in the middle of a tag.

Related errors


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