[
https://issues.apache.org/jira/browse/FLINK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16118345#comment-16118345
]
ASF GitHub Bot commented on FLINK-7387:
---------------------------------------
GitHub user tillrohrmann opened a pull request:
https://github.com/apache/flink/pull/4498
[FLINK-7387] [rpc] Require RpcEndpoints to directly implement RpcGateways
## What is the purpose of the change
This commit changes the relation between `RpcEndpoints` and `RpcGateways`.
From now on,
the `RpcEndpoints` have to implement the `RpcGateways` they want to support
instead of
coupling it loosely via a type parameter. In order to obtain self gateway a
new
method `RpcEndpoint#getSelfGateway(Class)` has been introduced. This method
can be used
to obtain the `RpcGateway` type at run time to talk to the `RpcEndpoint`
asynchronously.
All existing `RpcEndpoints` have been adapted to the new model. This
basically means
that they now return a CompletableFuture<X> instead of X.
## Brief change log
- Introduce `RpcServer` to encapsulate functionality previously contained
in `RpcEndpoint's` self gateway
- Adapt `RpcService` to start `RpcServer` with correct type bounds
- Let `RpcEndpoints` implement their respective `RpcGateways`
- Remove `RpcCompletenessTest` and `RpcMethod`
## Verifying this change
This change is already covered by existing tests:
- `AsyncCallsTest`, `AkkaRpcServiceTest`, `AkkaRpcActorTest`
This change added tests and can be verified as follows:
- Added `RpcEndpointTest` to ensure that extending `RpcEndpoints` works
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): (no)
- The public API, i.e., is any changed class annotated with
`@Public(Evolving)`: (no)
- The serializers: (no)
- The runtime per-record code paths (performance sensitive): (no)
- Anything that affects deployment or recovery: JobManager (and its
components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes (but only Flip-6))
## Documentation
- Does this pull request introduce a new feature? (no)
- If yes, how is the feature documented? (not applicable)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tillrohrmann/flink rpcRework
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/flink/pull/4498.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #4498
----
commit 858b27b96bf40377dba73a11bcd31d488b9a68cc
Author: Till Rohrmann <trohrm...@apache.org>
Date: 2017-08-08T12:43:47Z
[FLINK-7387] [rpc] Require RpcEndpoints to directly implement RpcGateways
This commit changes the relation between RpcEndpoints and RpcGateways. From
now on,
the RpcEndpoints have to implement the RpcGateways they want to support
instead of
coupling it loosely via a type parameter. In order to obtain self gateway a
new
method RpcEndpoint#getSelfGateway(Class) has been introduced. This method
can be used
to obtain the RpcGateway type at run time to talk to the RpcEndpoint
asynchronously.
All existing RpcEndpoints have been adapted to the new model. This
basically means
that they now return a CompletableFuture<X> instead of X.
Add RpcEndpointTest
----
> Let RpcEndpoint directly implement RpcGateways
> ----------------------------------------------
>
> Key: FLINK-7387
> URL: https://issues.apache.org/jira/browse/FLINK-7387
> Project: Flink
> Issue Type: Sub-task
> Components: Distributed Coordination
> Affects Versions: 1.4.0
> Reporter: Till Rohrmann
> Assignee: Till Rohrmann
> Labels: flip-6
>
> Right now, a {{RpcGateway}} is only implicitly coupled to a {{RpcEndpoint}}
> by specifying it a s type argument and having the {{RpcCompletenessTest}}
> watching that the endpoint implements all methods of the gateway.
> This makes it possible that the endpoint and the gateway can have slightly
> different interfaces. E.g. the gateway defines a method which returns a
> {{Future<Integer>}} whereas this method is implemented by the endpoint as a
> method which returns {{Integer}}. This underlines the fact that the endpoint
> method call is synchronous whereas the gateway issues an asynchronous call.
> The downside is that it is very cumbersome to establish type hierarchies
> among {{RpcEndpoints}}. Thus, it is not easily possible to extend a specific
> {{RcpEndpoint}} to add testing RPCs, for example. Moreover, you rely on the
> {{RpcCompletenessTest}} to catch all not implemented methods instead of
> relying on the compiler.
> I think in the long run, it would be better to let the {{RpcEndpoints}}
> directly implement the {{RpcGateways}} because the benefits of being able to
> extend {{RpcEndpoints}} outweigh the benefits of the current approach.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
