[ISSUE #2435] Solve the problem that DefaultMQProducer#request() sends messages and waits for timeout synchronously

[li-xiao-shuang]

fix : #2435

1. Add the default namesrvAddr to the RequestProducer example
2. Solve the synchronization wait timeout problem because the semaphore does not decrease after DefaultMQProducer#request() message is sent successfully
3. Solve the problem that the callback method is not called after the DefaultMQProducer#request() message is sent successfully

[coveralls]

Coverage decreased (-0.06%) to 52.195% when pulling 7765d30 on li-xiao-shuang:feature_#2435 into 9445b78 on apache:develop.

[hzh0425]

According to the above logic, should 'putResponseMessage' also be called in line 1443? and the following request has the same problem?

[li-xiao-shuang]

According to the above logic, should 'putResponseMessage' also be called in line 1443? and the following request has the same problem?

Yes, I will deal with this separately. The other interfaces are special. I am still familiar with MQ

[codecov-commenter]

Codecov Report

Merging #4313 (7765d30) into develop (9445b78) will decrease coverage by 0.03%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             develop    #4313      +/-   ##
=============================================
- Coverage      48.18%   48.14%   -0.04%     
+ Complexity      5085     5072      -13     
=============================================
  Files            642      642              
  Lines          42780    42782       +2     
  Branches        5599     5599              
=============================================
- Hits           20614    20598      -16     
- Misses         19650    19670      +20     
+ Partials        2516     2514       -2     

Impacted Files	Coverage Δ
...mq/client/impl/producer/DefaultMQProducerImpl.java	44.32% <0.00%> (-0.11%)	⬇️
...rg/apache/rocketmq/common/stats/StatsSnapshot.java	84.61% <0.00%> (-15.39%)	⬇️
...ache/rocketmq/common/stats/MomentStatsItemSet.java	39.13% <0.00%> (-13.05%)	⬇️
.../apache/rocketmq/common/stats/MomentStatsItem.java	38.09% <0.00%> (-9.53%)	⬇️
...va/org/apache/rocketmq/common/stats/StatsItem.java	50.83% <0.00%> (-5.00%)	⬇️
...org/apache/rocketmq/common/stats/StatsItemSet.java	44.77% <0.00%> (-2.99%)	⬇️
...mq/client/impl/consumer/RebalanceLitePullImpl.java	72.05% <0.00%> (-1.48%)	⬇️
...e/rocketmq/client/impl/consumer/RebalanceImpl.java	43.75% <0.00%> (-0.79%)	⬇️
...a/org/apache/rocketmq/store/StoreStatsService.java	36.97% <0.00%> (-0.57%)	⬇️
...ent/impl/consumer/DefaultLitePullConsumerImpl.java	68.79% <0.00%> (-0.52%)	⬇️
... and 8 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9445b78...7765d30. Read the comment docs.

[hzh0425]

According to the above logic, should 'putResponseMessage' also be called in line 1443? and the following request has the same problem?

Yes, I will deal with this separately. The other interfaces are special. I am still familiar with MQ

Okay, nice try

[martincao12]

这么修改相当于在执行sendCallback的onSuccess的时候就立即执行了requestResponseFuture的putResponseMessage或者executeRequestCallback，这俩不是应该在收到replyMsg之后再执行吗，即ClientRemotingProcessor里processReplyMessage做的事情？看Issue #2435里的报错，是因为broker reply msg的时候，request请求的producer已经unregister了。 cc @duhenglucky