We were of at the Flink Forward conference the last week, so slow progress on PRs...
In principle, the design looks fine. To double check: - Does HDFS permit to rename to an already existing file name (replacing that existing file)? - If yes, this sounds reasonable. If not, this could be an issue (need to delete the original file before rename, failure in that case means file does not exist on recovery). There is another option to approach this: - The recoverable writer has the option to say if it can also "recover for resume" or only "recover for commit". "Recover for resume" leads to appending to the started file, while only supporting "recover for commit" means that a new part file would be started after recovery. - This version could declare itself to only "recover for commit", in which case we would never have to go back to the original file name, but only copy from the "part in progress"-file to the published file name, avoiding the above problem. - That would mean we need to have the "truncater" handle the "truncate existing file back" logic and "truncating rename". The legacy hadoop handler would only implement the second - truncating rename. [ Full content available at: https://github.com/apache/flink/pull/6608 ] This message was relayed via gitbox.apache.org for [email protected]
