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

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

Github user pnowojski commented on a diff in the pull request:

    https://github.com/apache/flink/pull/4559#discussion_r152008221
  
    --- Diff: 
flink-runtime/src/main/java/org/apache/flink/runtime/io/network/partition/SpillableSubpartitionView.java
 ---
    @@ -145,6 +145,10 @@ public Buffer getNextBuffer() throws IOException, 
InterruptedException {
                                        listener.notifyBuffersAvailable(1);
                                }
     
    +                           if (current.isBuffer()) {
    --- End diff --
    
    This logic is a copy/paste with `SpilledSubpartitionView` and 
`PipelinedSubpartition`. It gets even more complicated in next PR. 
    
    How about changing `ResultSubpartitionView` to an abstract class with 
`ResultSubpartition parent` field and following methods:
    ```
    Buffer getNextBuffer() throws IOException, InterruptedException {
        Buffer next = getNextBufferInternal();
        if (buffer != null) {
                parent.decreaseStatistics(buffer);
        }
        return next;
    }
    
    protected abstract Buffer getNextBufferInternal() throws IOException, 
InterruptedException;
    ``` 
    And rename all current implementations of `getNextBuffer` to 
`getNextBufferInternal`.
    
    Thus:
    1. You wouldn't have to reimplement and handle decrementing in many places, 
but only one
    2. `protected int backlog;` field from `ResultSubpartition` could be made 
private.


> 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)

Reply via email to