[
https://issues.apache.org/jira/browse/FLINK-23981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17405152#comment-17405152
]
Chesnay Schepler commented on FLINK-23981:
------------------------------------------
> I checked it with the "/jars" request, and I repeated this test multiple
> times.
On it's own this isn't too interesting; you might just have hit the same JM
that couldn't see the file earlier. Ideally you'd check the filesystem because
that's the source-of-truth.
> Can [the shared filesystem] be related to the issue?
Possibly; it depends on the visibility guarantees that the backing filesystem
provides.
Maybe one of your JM is misconfigured and not even using this filesystem.
It could of course also be that some other process has deleted the file; we saw
cases in the past where this happened when people use /tmp for this stuff.
You aren't doing anything like broadcasting these requests to multiple JMs, are
you?
> Delete file request returns an error even though the operation succeeded
> ------------------------------------------------------------------------
>
> Key: FLINK-23981
> URL: https://issues.apache.org/jira/browse/FLINK-23981
> Project: Flink
> Issue Type: New Feature
> Components: Runtime / REST
> Affects Versions: 1.13.1, 1.13.2
> Reporter: Leonid Ilyevsky
> Priority: Minor
>
> When deleting the previously uploaded file, I get http response with the
> error, complaining that the file does not exist.
> The file obviously does not exist AFTER it is deleted - maybe the check is
> done in the wrong place in the code?
> The delete operation actually succeeds, so as a workaround, I simply ignore
> the error; instead I check whether the file is actually gone (by making
> another REST call).
>
> I guess, the delete call should return some sort of success response instead
> of an error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
