You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/08/17 16:24:00 UTC

[jira] [Commented] (FLINK-7468) Implement Netty sender backlog logic for credit-based

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

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

GitHub user zhijiangW opened a pull request:

    https://github.com/apache/flink/pull/4559

    [FLINK-7468][network]Implement Netty sender backlog logic for credit-based

    ## What is the purpose of the change
    
    This PR is based on #4533 whose commits are also included for passing travis. Review the last commit for this PR change.
    
    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. So the backlog is attached in `BufferResponse` by sender as an absolute value after the buffer being transferred.
    
    ## Brief change log
    
      - *Adds the `getBacklog` method in `ResultSubpartitionView`*
      - *The `ResultSubpartition maintains the backlog to increase value when adding buffer to it and decrease value when polling buffer from it*
    
    ## Verifying this change
    
    This change will be covered by the test case in next PR.
    
    ## Does this pull request potentially affect one of the following parts:
    
      - Dependencies (does it add or upgrade a dependency): (no)
      - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: (no)
      - The serializers: (no)
      - The runtime per-record code paths (performance sensitive): (no)
      - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (no)
    
    ## Documentation
    
      - Does this pull request introduce a new feature? (no)
      - If yes, how is the feature documented? (not applicable)
    


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/zhijiangW/flink FLINK-7468

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/flink/pull/4559.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #4559
    
----
commit e35c1ff8066bf44344495d132a1092b9db3ef182
Author: Zhijiang <wa...@aliyun.com>
Date:   2017-08-07T09:31:17Z

    [FLINK-7378][core]Create a fix size (non rebalancing) buffer pool type for the floating buffers

commit 969c24d3bf80c1ff89ada11e81b9bf4fea14066f
Author: Zhijiang <wa...@aliyun.com>
Date:   2017-08-14T06:30:47Z

    [FLINK-7394][core]Implement basic InputChannel with free buffers,credit and backlog

commit 15fa828449d73f53042c57e9c5494d75ddee575f
Author: Zhijiang <wa...@aliyun.com>
Date:   2017-08-10T05:29:13Z

    [FLINK-7406][network]Implement Netty receiver incoming pipeline for credit-based

commit d0674244f15701863a5dd3f68b7274b3bd49c64d
Author: Zhijiang <wa...@aliyun.com>
Date:   2017-08-12T14:13:25Z

    [FLINK-7416][network] Implement Netty receiver outgoing pipeline for credit-based

commit 102f80916534719465cbbaf788ef09a57ca22879
Author: Zhijiang <wa...@aliyun.com>
Date:   2017-08-17T11:38:45Z

    [FLINK-7468][network]Implement Netty sender backlog logic for credit-based

----


> Implement Netty 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.4.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)