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

optimize: refactoring rpc request method and rpc interface. #2540

Merged
merged 101 commits into from
Jul 13, 2020

Conversation

objcoding
Copy link
Contributor

@objcoding objcoding commented Apr 12, 2020

Ⅰ. Describe what this PR did

this pr base on phase3:#2486

  1. refactoring rpc request method:
    (1) AbstractRemoting
    Object sendSync(Channel channel, RpcMessage rpcMessage, long timeoutMillis) throws TimeoutException
    void sendAsync(Channel channel, RpcMessage rpcMessage)
    (2) RemotingClient
    Object sendSyncRequest(Object msg) throws TimeoutException;
    Object sendSyncRequest(Channel channel, Object msg) throws TimeoutException;
    void sendAsyncRequest(Channel channel, Object msg);
    void sendAsyncResponse(String serverAddress, RpcMessage rpcMessage, Object msg);
    (3) RemotingServer
    Object sendSyncRequest(String resourceId, String clientId, Object msg) throws TimeoutException;
    Object sendSyncRequest(Channel channel, Object msg) throws TimeoutException;
    void sendAsyncRequest(Channel channel, Object msg);
    void sendAsyncResponse(RpcMessage rpcMessage, Channel channel, Object msg);

  2. Name optimization and class classification.

  3. remove AbstractNettyRemotingSever.

Ⅱ. Does this pull request fix one issue?

refactoring tasks: #2313

ⅡⅠ. Method call

Two fixed rpc communication methods: sendSync and sendAsync method, client and server can freely extend the request method, and finally send messages through sendSync and sendAsync method.
image
image

ⅠV. Remote service interface relationship

image
image

# Conflicts:
#	core/src/main/java/io/seata/core/rpc/netty/AbstractRpcRemoting.java
*/
Object sendMsgWithResponse(String serverAddress, Object msg, long timeout) throws TimeoutException;
Object sendSyncRequest(Channel channel, Object msg) throws TimeoutException;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should there be a channel parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At that time, why the channel invaded the RemotingClient interface was also a helpless choice, because when called in many places, the various parameters were not uniform, it was difficult to remove the dependency of the channel. At that time, my idea was,

  1. RemotingClient as a top-level interface, when other rpc types are added in the future, their interfaces can be added to this top-level interface
  2. Remove the netty-related dependencies and make a RemotingClient that is truly irrelevant to the specific rpc type
    In the end I chose the first and easiest method to refactor.

I would like to add a pr later to improve it.

Copy link
Contributor

@l81893521 l81893521 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@slievrly slievrly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@slievrly slievrly changed the title optimize: refactoring rpc request method and rpc interface relationship. optimize: refactoring rpc request method and rpc interface. Jul 13, 2020
@slievrly slievrly merged commit d1b2f1f into apache:develop Jul 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
module/core core module module/rm-datasource rm-datasource module module/server server module
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants