[
https://issues.apache.org/jira/browse/FLINK-7468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16296452#comment-16296452
]
ASF GitHub Bot commented on FLINK-7468:
---------------------------------------
Github user zhijiangW commented on a diff in the pull request:
https://github.com/apache/flink/pull/4559#discussion_r157691096
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/io/network/partition/PipelinedSubpartition.java
---
@@ -52,6 +54,10 @@
/** Flag indicating whether the subpartition has been released. */
private volatile boolean isReleased;
+ /** The number of non-event buffers currently in this subpartition */
+ @GuardedBy("buffers")
+ private volatile int buffersInBacklog;
--- End diff --
The way of `ArrayDeque#size()` for `getBuffersInBacklog()` may be not
feasible because we do not know how many events in the `ArrayDeque` and they
should not be considered as backlog length.
For the new API, we may need to modify the
`ResultSubpartitionView#getNextBuffer` to return `BufferAndBacklog` wrapping
structure instead of `Buffer`, and do we also need to extend the
`BufferAndAvailability` to add backlog in it? By this way, it can get benefits
for `PipelinedSubpartition` to reduce 'volatile`, but for
`SpillableSubpartition`, the `volatile` may still be needed? Because the
`getNextBuffer` and `decreaseBacklog` are in different parts for
`SpillableSubpartitionView/SpilledSubpartitionView`.
> Implement sender backlog logic for credit-based
> -----------------------------------------------
>
> Key: FLINK-7468
> URL: https://issues.apache.org/jira/browse/FLINK-7468
> Project: Flink
> Issue Type: Sub-task
> Components: Network
> Reporter: zhijiang
> Assignee: zhijiang
> Fix For: 1.5.0
>
>
> This is a part of work for credit-based network flow control.
> Receivers should know how many buffers are available on the sender side (the
> backlog). The receivers use this information to decide how to distribute
> floating buffers.
> The {{ResultSubpartition}} maintains the backlog which only indicates the
> number of buffers in this subpartition, not including the number of events.
> The backlog is increased for adding buffer to this subpartition, and
> decreased for polling buffer from it.
> The backlog is attached in {{BufferResponse}} by sender as an absolute value
> after the buffer being transferred.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)