[
https://issues.apache.org/jira/browse/FLINK-17413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zhijiang updated FLINK-17413:
-----------------------------
Description:
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.
was:
In RemoteInputChannel, we already have the states of
`lastRequestedCheckpointId` and `receivedCheckpointId` to control whether the
received buffer should be notified to unaligner component.
In current ThreadSafeUnaligner, the variable `storeNewBuffers` is also used for
similar purpose to deciding whether the notified buffer should be written into
persister. In other words, as long as the `RemoteInputChannel` decides to
notify this received buffer, it should be always needed to spill. So we can
remove the variable `storeNewBuffers` from ThreadSafeUnaligner completely.
> 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
>
> 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)
