Eliminating False Empty Responses in RocketMQ 5.0 SimpleConsumer with Adaptive Proxy

RocketMQ 5.0 introduced a Proxy module, a stateless pop consumption mechanism, and a new client type called SimpleConsumer . While the pop mechanism solves load‑balancing problems during client publish or offline events, it creates a new challenge: when both client count and message volume are low, consumption latency may occur.

Background

Traditional messaging products use a long‑polling model where the client sends a request with a relatively long timeout that remains pending until a message appears or the timeout expires.

Problem with Existing Long‑Polling after Proxy Introduction

After adding Proxy, the client‑side long poll becomes tightly coupled with the Proxy‑to‑Broker long poll. A single client long poll to the Proxy triggers exactly one long poll from the Proxy to a specific Broker. If the selected Broker has no messages, the request hangs, even though other Brokers may have ready messages. This results in a “false empty response,” where the client cannot receive messages in real time.

Insights from Other Products

For example, MNS splits the long‑polling interval into multiple short‑polling slices to cover all Brokers. It first issues several short‑poll requests to each Broker; if the short‑poll quota is exhausted, it falls back to a long poll. However, this approach still cannot guarantee coverage when the poll window is short or the number of Brokers is large, leading to timing mismatches.

Proposed Technical Solution

The goal is to decouple the client‑side long poll from the Broker‑side long poll and give the Proxy awareness of which Brokers have pending messages, allowing it to preferentially query those Brokers without introducing extra state.

Decouple client long poll and Broker long poll, and enable Proxy to sense backend message counts.

Keep the design stateless, matching the Pop consumption semantics, avoiding additional state in the Proxy.

Maintain simplicity and reliability.

We introduce a NOTIFICATION mechanism that lets the Proxy learn whether a Broker holds unconsumed messages. With this information, the Proxy can make smarter pull decisions.

Pop with Notify

A client request is abstracted as a long‑poll task composed of a notification sub‑task and a request sub‑task.

The notification sub‑task checks each Broker for pending messages via a Notification request.

If a message is found, the result is queued and a Pop request is issued; otherwise, the task may end or continue with further notifications.

When a notification returns a positive result, the Proxy can immediately pull the message. In distributed environments with multiple proxies, a queue is used to cache notification results to avoid duplicate pulls.

The consumption task retrieves results from the queue, acquires a lock to ensure only one consumption per long‑poll task, and returns the message if available. If no result is found, it assumes another concurrent consumer has already processed the message.

Adaptive Switching

When request volume is high, the system can revert to the original pop‑long‑poll approach. The Proxy monitors the current pop request count; if it falls below a threshold, it switches to the pop‑with‑notify mode, otherwise it stays with the traditional long poll.

Metrics for Evaluation

Number of client‑initiated long polls (is_long_polling).

Number of pop‑with‑notify invocations (tracked via existing RPC metrics).

First‑pop hit count (is_short_polling_hit) – cases where a message is retrieved without triggering notify.

Usage Guidance

Define a minimum long‑poll timeout (e.g., AWS uses 1 second; RocketMQ server enforces a 5‑second minimum configurable via ProxyConfig#grpcClientConsumerMinLongPollingTimeoutMillis). For SimpleConsumer, adjust the awaitDuration field.

SimpleConsumer consumer = provider.newSimpleConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setConsumerGroup(consumerGroup)
    // set await duration for long‑polling.
    .setAwaitDuration(awaitDuration)
    .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
    .build();

Conclusion

The presented design delivers a stateless, real‑time consumption solution for RocketMQ 5.0 SimpleConsumer. By decoupling client and broker polls and leveraging a notification‑driven proxy, it eliminates false empty responses, improves latency, and reduces unnecessary network traffic compared with the previous PushConsumer long‑polling model.