[
https://issues.apache.org/jira/browse/FLINK-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16956148#comment-16956148
]
Kenneth William Krugler commented on FLINK-14472:
-------------------------------------------------
Did the issue ever get fixed, where asynchronous I/O back-pressure wasn't being
reported? This was also due to how detection of back-pressure was tied to where
threads were blocked. From [~trohrmann]'s email on March 25th, 2019:
{quote}I think Seed is correct that we don't properly report backpressure from
an AsyncWaitOperator. The problem is that not the Task's main execution thread
but the Emitter thread will emit the elements and, thus, be stuck in the
`requestBufferBuilderBlocking` method.
{quote}
If that's still an outstanding issue, I'm wondering if the above change would
also fix it.
> Implement back-pressure monitor with non-blocking outputs
> ---------------------------------------------------------
>
> Key: FLINK-14472
> URL: https://issues.apache.org/jira/browse/FLINK-14472
> Project: Flink
> Issue Type: Task
> Components: Runtime / Network
> Reporter: zhijiang
> Assignee: Yingjie Cao
> Priority: Minor
> Fix For: 1.10.0
>
>
> 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 already implemented the non-blocking output for the first case in
> [FLINK-14396|https://issues.apache.org/jira/browse/FLINK-14396], and we
> expect the second case done together with adjusting the back-pressure monitor
> which could check for `RecordWriter#isAvailable` instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
