You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "zhijiang (Jira)" <ji...@apache.org> on 2019/11/14 16:31:00 UTC

[jira] [Closed] (FLINK-14472) Implement back-pressure monitor with non-blocking outputs

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

zhijiang closed FLINK-14472.
----------------------------
    Resolution: Fixed

Merged in master: a9b126640c41b767c26b5a1537a45c3102574a3c

> Implement back-pressure monitor with non-blocking outputs
> ---------------------------------------------------------
>
>                 Key: FLINK-14472
>                 URL: https://issues.apache.org/jira/browse/FLINK-14472
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Runtime / Network
>            Reporter: zhijiang
>            Assignee: Yingjie Cao
>            Priority: Minor
>              Labels: pull-request-available
>             Fix For: 1.10.0
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently back-pressure monitor relies on detecting task threads that are stuck in `requestBufferBuilderBlocking`. There are actually two cases to cause back-pressure ATM:
>  * There are no available buffers in `LocalBufferPool` and all the given quotas from global pool are also exhausted. Then we need to wait for buffer recycling to `LocalBufferPool`.
>  * No available buffers in `LocalBufferPool`, but the quota has not been used up. While requesting buffer from global pool, it is blocked because of no available buffers in global pool. Then we need to wait for buffer recycling to global pool.
> We try to implement the non-blocking network output in FLINK-14396, so the back pressure monitor should be adjusted accordingly after the non-blocking output is used in practice.
> In detail we try to avoid the current monitor way by analyzing the task thread stack, which has some drawbacks discussed before:
>  * If the `requestBuffer` is not triggered by task thread, the current monitor is invalid in practice.
>  * The current monitor is heavy-weight and fragile because it needs to understand more details of LocalBufferPool implementation.  
> We could provide a transparent method for the monitor caller to get the backpressure result directly, and hide the implementation details in the LocalBufferPool.



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