[
https://issues.apache.org/jira/browse/FLINK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16123242#comment-16123242
]
ASF GitHub Bot commented on FLINK-7387:
---------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/flink/pull/4498
> 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
> Fix For: 1.4.0
>
>
> 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)
