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

Stephan Ewen commented on FLINK-17820:
--------------------------------------

I see. You cannot rely on {{close()}} here as well, because that closes the 
underlying stream in a "close for dispose" manner. That is indeed a bit of a 
design shortcoming in the {{CheckpointStateOutputStream}} class.

My feeling is that this assumption of {{DataOutputStream}} being non-buffering 
is made in some other parts of the code.
What do you think about adding a test that guards this assumption?

We also have the {{DataOutputViewStreamWrapper}} class which is an extension of 
{{DataOutputStream}} - we could use that, guard it with a "does not buffer" 
test and if we ever find it actually buffers, then we need to implement the 
methods directly, rather than inherit from {{DataOutputStream}}.




> Memory threshold is ignored for channel state
> ---------------------------------------------
>
>                 Key: FLINK-17820
>                 URL: https://issues.apache.org/jira/browse/FLINK-17820
>             Project: Flink
>          Issue Type: Bug
>          Components: Runtime / Checkpointing, Runtime / Task
>    Affects Versions: 1.11.0
>            Reporter: Roman Khachatryan
>            Assignee: Roman Khachatryan
>            Priority: Critical
>              Labels: pull-request-available
>             Fix For: 1.11.0
>
>
> Config parameter state.backend.fs.memory-threshold is ignored for channel 
> state. Causing each subtask to have a file per checkpoint. Regardless of the 
> size of channel state (of this subtask).
> This also causes slow cleanup and delays the next checkpoint.
>  
> The problem is that {{ChannelStateCheckpointWriter.finishWriteAndResult}} 
> calls flush(); which actually flushes the data on disk.
>  
> From FSDataOutputStream.flush Javadoc:
> A completed flush does not mean that the data is necessarily persistent. Data 
> persistence can is only assumed after calls to close() or sync().
>  
> Possible solutions:
> 1. not to flush in {{ChannelStateCheckpointWriter.finishWriteAndResult (which 
> can lead to data loss in a wrapping stream).}}
> {{2. change }}{{FsCheckpointStateOutputStream.flush behavior}}
> {{3. wrap }}{{FsCheckpointStateOutputStream to prevent flush}}{{}}{{}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to