[ISSUE apache#6726] Fix bug DefaultMQProducer#request method invoke t…

[hhy50]

[ISSUE #6726]

[codecov-commenter]

Codecov Report

Merging #6730 (bf4ac59) into develop (e369d7d) will decrease coverage by 0.10%.
The diff coverage is 35.68%.

@@              Coverage Diff              @@
##             develop    #6730      +/-   ##
=============================================
- Coverage      42.66%   42.56%   -0.10%     
- Complexity      9207     9226      +19     
=============================================
  Files           1131     1135       +4     
  Lines          80421    80525     +104     
  Branches       10511    10523      +12     
=============================================
- Hits           34310    34277      -33     
- Misses         41822    41975     +153     
+ Partials        4289     4273      -16     

Impacted Files	Coverage Δ
...cketmq/broker/processor/ReplyMessageProcessor.java	1.61% <0.00%> (-55.38%)	⬇️
.../rocketmq/client/impl/ClientRemotingProcessor.java	3.27% <0.00%> (+0.40%)	⬆️
...he/rocketmq/client/producer/DefaultMQProducer.java	60.88% <ø> (ø)
...va/org/apache/rocketmq/common/message/Message.java	52.80% <0.00%> (-1.85%)	⬇️
...g/apache/rocketmq/common/message/MessageReply.java	0.00% <0.00%> (ø)
...rocketmq/remoting/netty/NettyRemotingAbstract.java	51.27% <0.00%> (+0.63%)	⬆️
...apache/rocketmq/remoting/protocol/RequestCode.java	0.00% <ø> (ø)
...ing/protocol/header/ReplyMessageRequestHeader.java	0.00% <0.00%> (ø)
...g/apache/rocketmq/client/impl/MQClientAPIImpl.java	23.26% <12.50%> (-0.29%)	⬇️
.../java/org/apache/rocketmq/common/BrokerConfig.java	27.30% <25.00%> (ø)
... and 16 more

... and 20 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[tsunghanjacktsai]

Hey @haiyanghan , thanks for your effort at first. I probably see what you're trying to do here according to the issue you created, but the meaning of message sending in MQ just simply means that the Broker would return a corresponding response once the message arrived without waiting it to be consumed. Of course, you could detail your thought if I've misunderstood your intention for doing this.

[hhy50]

Hey @haiyanghan , thanks for your effort at first. I probably see what you're trying to do here according to the issue you created, but the meaning of message sending in MQ just simply means that the Broker would return a corresponding response once the message arrived without waiting it to be consumed. Of course, you could detail your thought if I've misunderstood your intention for doing this.

Yes, when the message arrives at the broker, it returns, which is the logic of the original request method.
But the request method should be based on the request reply mode, waiting for the message to be consumed

[hhy50]

Hey @haiyanghan , thanks for your effort at first. I probably see what you're trying to do here according to the issue you created, but the meaning of message sending in MQ just simply means that the Broker would return a corresponding response once the message arrived without waiting it to be consumed. Of course, you could detail your thought if I've misunderstood your intention for doing this.

Sorry, my English proficiency is not very good and the problem description is not very clear

[aaron-ai]

Why is the SEND_REPLY_MESSAGE_V2 being removed? Will this cause any compatibility issues?

[hhy50]

there may compatibility issues, A better way is to add a new one SEND_REPLY_MESSAGE_V3 request code and RequestCodeProcessor

[hhy50]

@aaron-ai hi, I have optimized the compatibility issue, Preserved SEND_ REPLY_ MESSAGE and SEND_ REPLY_ MESSAGE_ V2 request code And the corresponding processor

[github-actions]

This PR is stale because it has been open for 365 days with no activity. It will be closed in 3 days if no further activity occurs. If you wish not to mark it as stale, please leave a comment in this PR.

[github-actions]

This PR was closed because it has been inactive for 3 days since being marked as stale.