ESB Debugging Guide: Concepts, Telnet Commands, and Troubleshooting Steps

Before working with ESB, refer to the internal wiki (http://wiki.58corp.com/index.php?title=%E6%9E%B6%E6%9E%84%E9%83%A8) to understand the environment, especially the key, subjectId, and clientId parameters.

Concepts

subjectId is a channel that identifies a type of message; producers and consumers use it to exchange messages. clientId identifies a subscriber; each clientId must consume the message at least once, depending on the propagation type. Both subjectId and clientId need to be applied for use, e.g., RD applied for subjectId=14006.

The ESB registration center key determines which ESB service address is returned; ensure the test environment uses the offline registration center and a valid offline key. Current offline ESB servers are 10.9.192.104 and 10.9.192.105 on port 30011, and access requires sandbox permissions.

Topic Prefix

In offline environments, a prefix is added to the online topic number to avoid message mixing across multiple test suites. The mapping can be found in the "转转线下ESB和MQ梳理" document.

Telnet Commands

When a consumer receives no messages, first verify whether the producer has generated messages. The following commands help locate the issue:

1. count‑sub <subjectId>

telnet 10.9.192.104 30011

Trying 10.9.192.104...

Connected to 10.9.192.104.

Escape character is '^]'.

count-sub 4014006

subject [4014006]

client in out persist

2               0          260655               0

1          329400          329407               0

3               0          329264               0

This output shows inbound and outbound message counts, helping determine if messages are queued.

2. list‑sub <subjectId>

list-sub 4014006

subjectName            clientId            ip:port

4014006                1       10.135.4.204:46213

4014006                1       192.168.186.159:34238

4014006                3       192.168.183.71:27295

4014006                3       192.168.183.78:33508

4014006                3       192.168.183.72:9867

The list shows which client IDs and IPs are subscribed, allowing you to verify whether the consumer process is running.

3. list‑sender <subjectId>

list-sender 4014006

{[subject is: 4014006, sender is: 192.168.183.77:3112,192.168.183.78:24296,192.168.183.79:55530,192.168.183.148:48002,192.168.183.72:51841,192.168.183.79:30766,192.168.183.148:12955,192.168.183.79:13492,192.168.183.148:23099,192.168.183.148:33249,192.168.183.148:40314,192.168.183.148:48079,192.168.183.148:61084,192.168.183.78:15811,192.168.183.79:62023,192.168.183.77:8027,]}

This displays the producer connections, helping confirm whether messages are being sent.

If the consumer is connected but no messages appear, the producer may not be generating them. If both producer and consumer are active yet no messages flow, the issue might be with ESB itself (e.g., outdated JARs), and you should involve the operations team with evidence.

Q&A

Q: What is the purpose of a topic number?

A: The subjectId marks the message type; different numbers represent different message categories.

Q: What does clientId do?

A: clientId distinguishes subscribers. In cluster consumption, multiple instances compete for messages; in broadcast consumption, every instance receives a copy. The diagram (included in the original) illustrates this behavior.

Q: Do producers have clientId?

A: No.

Q: Is mixing sandbox and production topics problematic?

A: Yes, sandbox consumers may pre‑empt production messages. Adding a prefix can isolate sandbox traffic, but it does not solve all cross‑environment issues.

Q: Why add a prefix to topic numbers in test environments?

A: To prevent message collisions across multiple test suites; without it, messages from one suite could be consumed by another.

ESB vs. MQ

Both provide asynchronous processing and decoupling, but differ in control and consumption models:

Cluster vs. broadcast consumption is controlled by the ESB server, while RocketMQ uses configuration files.

RocketMQ pulls messages (pseudo‑push); ESB can push or pull, defaulting to push.

ESB offers a monitoring platform (wmb) to view consumption status; RocketMQ relies on offsets and does not track individual message acknowledgments.

Article originally published on 2017‑02‑20 by 陈小凡.