You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by GitBox <gi...@apache.org> on 2018/08/01 06:28:49 UTC

[GitHub] kl0u opened a new pull request #6466: [FLINK-10005][DataStream API] StreamingFileSink: sets initialPartCounter=maxUsed in new Buckets

kl0u opened a new pull request #6466: [FLINK-10005][DataStream API] StreamingFileSink: sets initialPartCounter=maxUsed in new Buckets
URL: https://github.com/apache/flink/pull/6466
 
 
   ## What is the purpose of the change
   
   In the `StreamingFileSink` whenever a new bucket is created, we provide it with the initial part counter to use for its part files. In addition, when a bucket has no in-progress or pending files, it is removed from the state. 
   
   This behavior was leading to the problem:
   * bucket X starts with partCounter = 0
   * creates a new part file, i.e. partCounter = 1
   * everything gets committed and bucket X is empty so it gets removed from the state.
   * a new element comes in, and the bucket starts again with 0.
   
   This was solved for when recovering from a failure, but not if this deletion and creation of a bucket happens in normal execution. This PR solves this issue.
   
   ## Brief change log
   
   We change the `initialPartCounter` argument passed when creating a new bucket, to be the `max` across all local buckets. This allows to be sure that we do not ovewrite anything and also we do not need to the `blind searches` for file names in order to determine a valid part counter. The latter would not work in eventually-consistent filesystems.
   
   ## Verifying this change
   
   Updated existing tests to cover this scenario.
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): (yes / **no**)
     - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: (yes / **no**)
     - The serializers: (yes / **no** / don't know)
     - The runtime per-record code paths (performance sensitive): (yes / **no** / don't know)
     - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / **no** / don't know)
     - The S3 file system connector: (yes / **no** / don't know)
   
   ## Documentation
   
     - Does this pull request introduce a new feature? (yes / **no**)
     - If yes, how is the feature documented? (**not applicable** / docs / JavaDocs / not documented)
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services