flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-10005) StreamingFileSink ignores checkpoint/processing time rolling policies
Date Wed, 01 Aug 2018 06:29:00 GMT

    [ https://issues.apache.org/jira/browse/FLINK-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16564801#comment-16564801
] 

ASF GitHub Bot commented on FLINK-10005:
----------------------------------------

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


> StreamingFileSink ignores checkpoint/processing time rolling policies
> ---------------------------------------------------------------------
>
>                 Key: FLINK-10005
>                 URL: https://issues.apache.org/jira/browse/FLINK-10005
>             Project: Flink
>          Issue Type: Bug
>          Components: Streaming Connectors
>    Affects Versions: 1.6.0
>            Reporter: Chesnay Schepler
>            Assignee: Kostas Kloudas
>            Priority: Blocker
>              Labels: pull-request-available
>             Fix For: 1.6.0
>
>
> The {{StreamingFileSink}} supports different policies to determine whether a new part
file should be created; on each checkpoint, once a certain size is reached or on processing
time.
> This feature only works correctly for size thresholds, other policies are ignored.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message