Github user tillrohrmann commented on a diff in the pull request:
https://github.com/apache/flink/pull/6203#discussion_r198033040
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/rest/handler/job/JobSubmitHandler.java
---
@@ -54,18 +69,89 @@ public JobSubmitHandler(
@Override
protected CompletableFuture<JobSubmitResponseBody>
handleRequest(@Nonnull HandlerRequest<JobSubmitRequestBody,
EmptyMessageParameters> request, @Nonnull DispatcherGateway gateway) throws
RestHandlerException {
- JobGraph jobGraph;
- try {
- ObjectInputStream objectIn = new ObjectInputStream(new
ByteArrayInputStream(request.getRequestBody().serializedJobGraph));
- jobGraph = (JobGraph) objectIn.readObject();
- } catch (Exception e) {
- throw new RestHandlerException(
- "Failed to deserialize JobGraph.",
- HttpResponseStatus.BAD_REQUEST,
- e);
+ Collection<Path> uploadedFiles = request.getUploadedFiles();
--- End diff --
I agree that nio `Paths` are more powerful. I'm just wondering whether we
actually need this flexibility here. Usually it is a good idea to make the
interface as restrictive as possible and widen it on demand.
Moreover, there is also Flink's `Path` which comes with a bit of different
semantics. For example, you have the safety net for closing open file streams
which is also used to interrupt I/O operations which are otherwise not
interruptible. Mixing the nio paths in there, might give the false impression
that this also applies to them.
So I'm just saying that we should make this decision consciously and not
only based on which type is more convenient to be used.
---
