You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@rocketmq.apache.org by GitBox <gi...@apache.org> on 2020/04/14 16:46:18 UTC

[GitHub] [rocketmq] happyfeetw opened a new issue #1938: Logical Problem of sending method

happyfeetw opened a new issue #1938: Logical Problem of sending method
URL: https://github.com/apache/rocketmq/issues/1938

The issue tracker is **ONLY** used for bug report(feature request need to follow [RIP process](https://github.com/apache/rocketmq/wiki/RocketMQ-Improvement-Proposal)). Keep in mind, please check whether there is an existing same report before your raise a new one.

Alternately (especially if your communication is not a bug report), you can send mail to our [mailing lists](http://rocketmq.apache.org/about/contact/). We welcome any friendly suggestions, bug fixes, collaboration and other improvements.

Please ensure that your bug report is clear and that it is complete. Otherwise, we may be unable to understand it or to reproduce it, either of which would prevent us from fixing the bug. We strongly recommend the report(bug report or feature request) could include some hints as the following:

**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 check code 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 a 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 **are** some of queues that available, 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？

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

With regards,
Apache Git Services