Why RocketMQ Uses a Pull‑Based Long‑Polling Model That Feels Like Push

Consumption Model Overview

RocketMQ's consumer model is fundamentally pull‑based. The client continuously issues pull requests, but the broker holds each request (long‑polling) up to a configurable timeout (default 30 s). If new messages arrive during the hold, the broker immediately returns them, giving the consumer a push‑like experience.

Push vs Pull

Push : Broker pushes messages as soon as they arrive. High real‑time latency but requires the broker to track state for every consumer, leading to load imbalance.

Pull : Consumer initiates the request. Consumer controls consumption rate, improves fault tolerance, but real‑time depends on pull frequency.

Long‑Polling Mechanism

Consumer (e.g., DefaultMQPushConsumer) sends a pull request.

Broker checks the target queue:

If messages exist, they are returned immediately.

If the queue is empty, the broker suspends the request (default ≤30 s).

When a new message arrives, the suspended request is awakened and the message batch is sent to the consumer.

If the timeout expires without new messages, the broker returns an empty response and the client issues the next pull.

Consumer API Examples

// Push‑style consumer (actually long‑polling pull)
DefaultMQPushConsumer pushConsumer = new DefaultMQPushConsumer("group_name");
pushConsumer.subscribe("TopicTest", "*");
pushConsumer.registerMessageListener(new MessageListenerConcurrently() {
    @Override
    public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
            ConsumeConcurrentlyContext context) {
        System.out.println("Received message: " + new String(msgs.get(0).getBody()));
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
    }
});
pushConsumer.start();

// Raw pull consumer (manual offset management)
DefaultMQPullConsumer pullConsumer = new DefaultMQPullConsumer("group_name");
pullConsumer.start();
MessageQueue mq = ...; // obtain MessageQueue instance
long offset = ...; // track offset manually
PullResult pullResult = pullConsumer.pull(mq, "*", offset, 32);
// process PullResult

Best Practices

Use DefaultMQPushConsumer for most scenarios; it abstracts the long‑polling loop and provides a simple callback interface.

Adjust pull parameters to balance latency and broker load: setPullInterval(long ms) – interval between successive pull attempts. setPullBatchSize(int size) – number of messages fetched per request.

When precise control over pull cadence or replay logic is required, consider DefaultLitePullConsumer, which offers a streaming‑style API while still using the underlying pull mechanism.

Common Misconceptions

Push consumer is a true server‑side push. It is a client‑initiated long‑polling request; the broker does not actively push without a pending request.

Pull is always slower than push. With long‑polling, the perceived latency is comparable to push, while pull provides better scalability and fault tolerance.

Conclusion

RocketMQ achieves a push‑like experience by wrapping a pull‑based long‑polling mechanism inside the DefaultMQPushConsumer API. This design keeps the broker stateless, allows consumers to control their own consumption rate, and maintains high real‑time delivery.