[ https://issues.apache.org/jira/browse/FLINK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Till Rohrmann closed FLINK-7387. -------------------------------- Resolution: Fixed Fix Version/s: 1.4.0 Fixed via d95d20eb45185151d731c9b41e9b1ac22cf81334 > 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)