Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Logical Problem of sending method

See original GitHub issue

BUG REPORT I found a logical problem while reading source code. The problem method is located in org.apache.rocketmq.client.latency.MQFaultStrategy#selectOneMessageQueue(final TopicPublishInfo tpInfo, final String lastBrokerName).

The first problem is that when code runs into the first for-loop, it basically traverse the list of all message queue, and select one available to return. But when it checks the availability of the broker it got before, here comes the problem. In that checking block, it provides two conditions: null == lastBrokerName || mq.getBrokerName().equals(lastBrokerName). The second condition is the source of my problem. When this condition being triggered, it represents that producer need to re-send message and to pick one queue as target of sending. Meanwhile, this also means that the AVAILABLE broker is just the same broker it used last time, which is NOT AVAILABLE. It seemed to be wrong and should add a ! at start of the second condition. This is the first question.

The second question is, In this method, when calling tpInfo.getQueueIdByBroker(notBestBroker);, it returns an Integer variable named writeQueueNums represents the number of available queues under the notBestBroker for writting messages from producer. And under the situation that writeQueueNums is greater than zero, which means there exists certain amount of available queues, it in success calls ‘tpInfo.selectOneMessageQueue()’ to get an instance of MessageQueue. Then it checks the notBestBroker whether or not be null and set some info for mq. Is there any necessity for this "not-null"check? I don’t think so, for this notBestBroker itself has already been referenced. It’s contradictory and weird.

The 3rd question is that why it remove the notBestBroker from the list of failed(not available ) broker when there is no available queue to write?