You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@flink.apache.org by "Piotr Nowojski (Jira)" <ji...@apache.org> on 2020/05/19 13:52:00 UTC

[jira] [Updated] (FLINK-17413) Refactor the usages of ThreadSafeUnaligner#storeNewBuffers

     [ https://issues.apache.org/jira/browse/FLINK-17413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Piotr Nowojski updated FLINK-17413:
-----------------------------------
    Fix Version/s: 1.12.0

> Refactor the usages of ThreadSafeUnaligner#storeNewBuffers
> ----------------------------------------------------------
>
>                 Key: FLINK-17413
>                 URL: https://issues.apache.org/jira/browse/FLINK-17413
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Runtime / Checkpointing
>            Reporter: Zhijiang
>            Assignee: Zhijiang
>            Priority: Major
>             Fix For: 1.12.0
>
>
> In current ThreadSafeUnaligner, the variable `storeNewBuffers` has actually two usages. One is for avoiding duplicated counter for processing barrier or notifying received barrier for a respective channel. Another usage is for judging whether the notified buffer should be spilled by writer or not.
> In RemoteInputChannel, we already have the states  of `lastRequestedCheckpointId` and `receivedCheckpointId` to control whether the received buffer should be notified to unaligner component. In other words, as long as the `RemoteInputChannel` decides to notify this received buffer, it should be always needed to spill in ThreadSafeUnaligner. So we can remove the related condition inside ThreadSafeUnaligner#notifyBufferReceived and make the semantic of `storeNewBuffers` more clearly.



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