apache/rocketmq · error · RemotingCommandException

Failed to get max offset

Error message

Failed to get max offset

What it means

Thrown while a broker admin command (consume-stats / topic-offset enumeration in AdminBrokerProcessor) walks every write queue of a topic and calls MessageStore.getMaxOffsetInQueue(topic, i). The underlying getMaxOffsetInQueue declares ConsumeQueueException, and this wrapper converts it into a RemotingCommandException that fails the whole admin RPC. It means the broker could not read a consume queue to compute the max offset for at least one queue.

Source

Thrown at broker/src/main/java/org/apache/rocketmq/broker/processor/AdminBrokerProcessor.java:2761

                        && this.brokerController.getConsumerManager().findSubscriptionDataCount(group) > 0) {
                        LOGGER.warn(
                            "AdminBrokerProcessor#fetchAllConsumeStatsInBroker: topic does not exist in consumer "
                                + "group's subscription, topic={}, consumer group={}", topic, group);
                        continue;
                    }
                }

                for (int i = 0; i < topicConfig.getWriteQueueNums(); i++) {
                    MessageQueue mq = new MessageQueue();
                    mq.setTopic(topic);
                    mq.setBrokerName(this.brokerController.getBrokerConfig().getBrokerName());
                    mq.setQueueId(i);
                    OffsetWrapper offsetWrapper = new OffsetWrapper();
                    long brokerOffset;
                    try {
                        brokerOffset = this.brokerController.getMessageStore().getMaxOffsetInQueue(topic, i);
                    } catch (ConsumeQueueException e) {
                        throw new RemotingCommandException("Failed to get max offset", e);
                    }
                    if (brokerOffset < 0) {
                        brokerOffset = 0;
                    }
                    long consumerOffset = this.brokerController.getConsumerOffsetManager().queryOffset(
                        group,
                        topic,
                        i);
                    if (consumerOffset < 0)
                        consumerOffset = 0;

                    offsetWrapper.setBrokerOffset(brokerOffset);
                    offsetWrapper.setConsumerOffset(consumerOffset);

                    long timeOffset = consumerOffset - 1;
                    if (timeOffset >= 0) {
                        long lastTimestamp = this.brokerController.getMessageStore().getMessageStoreTimeStamp(topic, i, timeOffset);
                        if (lastTimestamp > 0) {

View on GitHub (pinned to 293f588571)

Solutions

  1. Check broker.log for the wrapped ConsumeQueueException cause (store layer) — it names the exact topic/queue and underlying IO error.
  2. Verify consume queue directory integrity for the affected topic (store/consumequeue/<topic>) and disk health.
  3. If the store failed to load a queue, restart the broker after fixing/recovering the store files; the admin call then succeeds.
  4. As a workaround, query offsets per-queue or use mqAdmin consumerProgress on a healthy replica/slave broker.
Defensive patterns

Strategy: retry

Validate before calling

// broker health gate before admin offset queries
boolean storeOk = brokerController.getMessageStore() instanceof DefaultMessageStore
    && !((DefaultMessageStore) brokerController.getMessageStore()).isShutdown();

Try / catch

catch (RemotingCommandException e) { if (e.getCause() instanceof ConsumeQueueException) { /* transient store issue: backoff and retry on another broker */ } throw e; }

Prevention

When it happens

Trigger: Calling GET_CONSUME_STATS / getAllConsumeOffset-style admin APIs for a topic whose ConsumeQueue is missing, corrupt, or unreadable; ConsumeQueue store backend (RocksDB) errors; queue files deleted while store is loading or after an unclean shutdown.

Common situations: Broker restarted after crash with damaged consume queue files; RocksDB consume queue enabled (enableRocksDBStore) and its directory is corrupted or on a failing disk; topic queues shrunk/deleted concurrently with the stats query.

Related errors


AI-assisted analysis of apache/rocketmq@293f588571 (2026-08-14). Data as JSON: /api/errors/2d04a1e893f78489. Report an issue: GitHub.