apache/rocketmq · error · RemotingTooMuchRequestException

call timeout

Error message

call timeout

What it means

RemotingTooMuchRequestException thrown by send(Message, MessageQueue, long timeout) when the local pre-send work (makeSureStateOK + Validators.checkMessage + the topic==mq equality check) alone consumed the whole timeout (costTime = now - beginStartTime >= timeout). Same deadline discipline as errors 274/275 but measured before sendKernelImpl is even entered - it almost always means the timeout argument is pathologically small, or validation is slow on huge message bodies (size checks over big arrays) under CPU pressure.

Source

Thrown at client/src/main/java/org/apache/rocketmq/client/impl/producer/DefaultMQProducerImpl.java:1240

     */
    public SendResult send(Message msg, MessageQueue mq)
        throws MQClientException, RemotingException, MQBrokerException, InterruptedException {
        return send(msg, mq, this.defaultMQProducer.getSendMsgTimeout());
    }

    public SendResult send(Message msg, MessageQueue mq, long timeout)
        throws MQClientException, RemotingException, MQBrokerException, InterruptedException {
        long beginStartTime = System.currentTimeMillis();
        this.makeSureStateOK();
        Validators.checkMessage(msg, this.defaultMQProducer);

        if (!msg.getTopic().equals(mq.getTopic())) {
            throw new MQClientException("message's topic not equal mq's topic", null);
        }

        long costTime = System.currentTimeMillis() - beginStartTime;
        if (timeout < costTime) {
            throw new RemotingTooMuchRequestException("call timeout");
        }

        return this.sendKernelImpl(msg, mq, CommunicationMode.SYNC, null, null, timeout);
    }

    /**
     * KERNEL ASYNC -------------------------------------------------------
     */
    public void send(Message msg, MessageQueue mq, SendCallback sendCallback)
        throws MQClientException, RemotingException, InterruptedException {
        send(msg, mq, sendCallback, this.defaultMQProducer.getSendMsgTimeout());
    }

    /**
     * @param msg
     * @param mq
     * @param sendCallback
     * @param timeout      the <code>sendCallback</code> will be invoked at most time

View on GitHub (pinned to 293f588571)

Solutions

1. Pass a realistic timeout (>= 1-3 seconds typical) and fix unit confusion at the call site (verify ms vs s)
2. Check the incoming deadline before calling send: if remaining budget < minimum (e.g. 100ms), fail fast or refresh the deadline instead of letting the client throw
3. If validation itself is slow (very large bodies), reduce message size / pre-validate at construction so the timed section stays cheap
4. Pin/monitor clock sync on hosts - NTP steps can fabricate timeouts (prefer chrony slew mode)

Example fix

// before
long deadlineNanos = ...;
producer.send(msg, mq, 50); // 50ms budget, validation alone exceeds it
// after
long budget = Math.max(1_000, remainingDeadlineMs());
producer.send(msg, mq, budget);

 long budget = Math.max(1_000, remainingDeadlineMs()); // never send with a starved budget
if (budget < 1_000) budget = 1_000; // floor the timeout at 1s
producer.send(msg, mq, budget);

try {
    return producer.send(msg, mq, timeout);
} catch (RemotingTooMuchRequestException e) {
    if ("call timeout".equals(e.getMessage())) {
        return producer.send(msg, mq, timeout * 4); // budget starved locally - retry larger
    }
    throw e;
}

When it happens

Trigger: triggerScenarios

Common situations: commonSituations

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• sendMessage call timeout
• sendDefaultImpl call timeout
• 13
• Sending message to topic[%s] is forbidden.
• Timeout must not be negative

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