Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RIP-16]Support request/response pattern #1422

Merged
merged 29 commits into from Nov 14, 2019

Conversation

@qqeasonchen
Copy link
Contributor

qqeasonchen commented Aug 28, 2019

What is the purpose of the change

this pr works for RIP-16.

Brief changelog

  • add request interface to producer;
  • add ReplyMessageProcessor in broker to support request-response model;

Verifying this change

XXXX

Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

  • Make sure there is a Github issue filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
  • Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add integration-test in test module.
  • Run mvn -B clean apache-rat:check findbugs:findbugs checkstyle:checkstyle to make sure basic checks pass. Run mvn clean install -DskipITs to make sure unit-test pass. Run mvn clean test-compile failsafe:integration-test to make sure integration-test pass.
  • If this contribution is large, please file an Apache Individual Contributor License Agreement.
@duhenglucky duhenglucky changed the title [ISSUE #1421]impl request-response model [RIP-16]impl request-response model Aug 28, 2019
@vongosling vongosling changed the title [RIP-16]impl request-response model [RIP-16]Support request/response pattern Aug 28, 2019
@vongosling vongosling added this to the 4.6.0 milestone Aug 28, 2019
@ShannonDing ShannonDing requested review from duhenglucky and vongosling Sep 2, 2019
@qqeasonchen qqeasonchen force-pushed the qqeasonchen:rocketmq-dev-rpc branch from 8451e3f to 7e221e5 Sep 11, 2019
qqeasonchen added 2 commits Sep 11, 2019
@coveralls

This comment has been minimized.

Copy link

coveralls commented Sep 16, 2019

Coverage Status

Coverage increased (+0.1%) to 50.442% when pulling c6cbab9 on qqeasonchen:rocketmq-dev-rpc into 5a8c4ed on apache:develop.

@RongtongJin

This comment has been minimized.

Copy link
Contributor

RongtongJin commented Sep 22, 2019

It would be better to add some unit tests.

Copy link
Contributor

duhenglucky left a comment

[Discuss]
Firstly, I wonder whether need a dependent ReplyMessageProcessor here, for the reply message, I think it just is a message that needs to push to the producer directly for accelerating, so how about just implement the executeSendMessageHookBefore method for push the message directly?

Another, compared with just starting a consumer in the producer side to consume a reply message from the ReplyTo topic, what are the advantages of current implementation? it seems that the current practice is difficult to achieve reliable asynchronous transmission, used in scenarios where message calls cannot fail. but this implementation indeed reduced response latency, especially in the condition that ReputService is a little busy :)

@qqeasonchen

This comment has been minimized.

Copy link
Contributor Author

qqeasonchen commented Oct 16, 2019

[Discuss]
Firstly, I wonder whether need a dependent ReplyMessageProcessor here, for the reply message, I think it just is a message that needs to push to the producer directly for accelerating, so how about just implement the executeSendMessageHookBefore method for push the message directly?

Another, compared with just starting a consumer in the producer side to consume a reply message from the ReplyTo topic, what are the advantages of current implementation? it seems that the current practice is difficult to achieve reliable asynchronous transmission, used in scenarios where message calls cannot fail. but this implementation indeed reduced response latency, especially in the condition that ReputService is a little busy :)

=====

  1. It's a feasible way to implement with 'executeSendMessageHookBefore', Adding ReplyMessageProcessor meant to make code more clearly. ReplyMessageProcessor push reply message to producer and store message, so it needs to handle both push result and put message result. If implement with executeSendMessageHookBefore, it would be a little more complex to handle the two result and return to producer. Both implement is Ok.
  2. There is a problem that rebalance result would change when new instance start or old instance stop. It is more complex to guarantee that reply message would be deliver to accurate producer.
qqeasonchen added 4 commits Oct 21, 2019
#	broker/src/main/java/org/apache/rocketmq/broker/BrokerController.java
@vongosling

This comment has been minimized.

Copy link
Member

vongosling commented Nov 8, 2019

@qqeasonchen You could click 'resolve conversation' button to close the resolved problems. It would be helpful for the community to watch things going on and push forward this feature to merge :-)

@duhenglucky duhenglucky merged commit e735fff into apache:develop Nov 14, 2019
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.1%) to 50.442%
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.