apache/rocketmq · error · RemotingCommandException

Failed to get max offset in queue

Error message

Failed to get max offset in queue

What it means

In Broker2Client's reset-offset flow, when the caller passes timeStamp == -1 (meaning 'reset to latest'), the broker resolves the latest offset via messageStore.getMaxOffsetInQueue(). Since getMaxOffsetInQueue declares ConsumeQueueException (a checked store-level failure), the processor wraps it in RemotingCommandException('Failed to get max offset in queue'). The resetOffset request therefore aborts before any offset table is pushed to consumers.

Source

Thrown at broker/src/main/java/org/apache/rocketmq/broker/client/net/Broker2Client.java:153

            MessageQueue mq = new MessageQueue();
            mq.setBrokerName(this.brokerController.getBrokerConfig().getBrokerName());
            mq.setTopic(topic);
            mq.setQueueId(i);

            long consumerOffset =
                this.brokerController.getConsumerOffsetManager().queryOffset(group, topic, i);
            if (-1 == consumerOffset) {
                response.setCode(ResponseCode.SYSTEM_ERROR);
                response.setRemark(String.format("THe consumer group <%s> not exist", group));
                return response;
            }

            long timeStampOffset;
            if (timeStamp == -1) {
                try {
                    timeStampOffset = this.brokerController.getMessageStore().getMaxOffsetInQueue(topic, i);
                } catch (ConsumeQueueException e) {
                    throw new RemotingCommandException("Failed to get max offset in queue", e);
                }
            } else {
                timeStampOffset = this.brokerController.getMessageStore().getOffsetInQueueByTime(topic, i, timeStamp);
            }

            if (timeStampOffset < 0) {
                log.warn("reset offset is invalid. topic={}, queueId={}, timeStampOffset={}", topic, i, timeStampOffset);
                timeStampOffset = 0;
            }

            if (isForce || timeStampOffset < consumerOffset) {
                offsetTable.put(mq, timeStampOffset);
            } else {
                offsetTable.put(mq, consumerOffset);
            }
        }

        ResetOffsetRequestHeader requestHeader = new ResetOffsetRequestHeader();

View on GitHub (pinned to 293f588571)

Solutions

  1. Check broker logs for the underlying ConsumeQueueException and the affected topic/queue
  2. Verify the topic and queue exist on this broker (topicRoute/queryTopic) before resetting offsets
  3. If consume queue files are damaged, recover or rebuild them (store recovery on restart) before retrying the reset
  4. Retry the admin operation when the broker store is fully healthy
Defensive patterns

Strategy: validation

Validate before calling

// before issuing resetOffset with latest semantics, confirm the queue is readable
long probe = brokerController.getMessageStore().getMinOffsetInQueue(topic, queueId);
if (probe < 0) throw new IllegalStateException("queue not available: " + topic + "-" + queueId);

Try / catch

try {
    adminExt.resetOffsetByTime(topic, group, timestamp);
} catch (Exception e) {
    Throwable real = ExceptionUtils.getRealException(e);
    if (real instanceof RemotingCommandException) { /* store-level failure: check broker logs, retry later */ }
}

Prevention

When it happens

Trigger: mqadmin resetOffsetByTime with no timestamp (latest) or the admin ResetOffset request with timeStamp=-1 against a topic/queue whose consume queue read fails in the store — e.g. queue files missing/corrupt or store in a failed state.

Common situations: Resetting offsets on a topic whose consume queue was manually deleted or corrupted; store shutdown in progress during the admin call; deleting a topic concurrently with resetOffset.

Related errors


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