Github user KurtYoung commented on a diff in the pull request:
https://github.com/apache/flink/pull/2550#discussion_r80837572
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/jobmaster/JobMaster.java
---
@@ -467,6 +487,128 @@ public void registerAtResourceManager(final String
address) {
//TODO:: register at the RM
}
+ @RpcMethod
+ public NextInputSplit requestNextInputSplit(final JobVertexID vertexID,
final ExecutionAttemptID executionAttempt) {
--- End diff --
I'm not sure that throw a exception by RpcMethod is a good way to do error
handling. From the caller's side, when the rpc method returns the Future from
gateway, caller can do error handling with handleAsync or exceptionallyAsync
now. But the exception from user logic with mess with all the exceptions from
rpc framework, like RpcTimeout or other exception that tells you that maybe the
rpc system does not work well. So typically you need to try to figure out what
went wrong by distinguishing the Exception type, which is not very elegant i
think.
One way we can do is we never throw exception in RpcMethod but deal with
error in the "ErrorCode" way by return the error explicitly with return value.
All the exception thrown when doing rpc call should due to the rpc framework.
In this situation, returning null is indicating that something wrong with
requesting. (If we should know more detail about error, we can rich it by
returning message, currently null will do the work)
And in normal case like no further split, we still return a NextInputSplit
with empty content in it.
What do you think about all these, let me know.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
