Hi, The inpoolQueueLength indicates hown many buffers are received and queued. But if the buffers in the queue are the events (like barrier), it will not be calculated in the inpoolUsage. So in your case it may be normal for these two metrics. If you monitored that the autoread=false in downstream side, that means the inpoolUsage may already reach 100% and there are no available buffers to receive data from upstream side. But if the upstream still has available buffers to output, the upstream will not be blocked in this case. BTW, if the autoread=false and the inpoolUsage reaches 100%, there may be a lot of buffers queued in front of barrier, so the checkpoint may expire as you said.
Best, Zhijiang ------------------------------------------------------------------ 发件人：aitozi <gjying1...@gmail.com> 发送时间：2018年9月18日(星期二) 12:59 收件人：user <user@flink.apache.org> 主 题：Re: InpoolUsage & InpoolBuffers inconsistence And my doubt for that comes from the debug of problem of checkpoint expiration. I encountered the checkpoint expiration with no backpressure shown in web ui. But after i add many log, i found that the barrier send to the downstream, And the downstream may be set to autoread = false , and block the consume of the barrier. But temporary in inputchannel do not cause the upstream backpressure. I think this situation can be monitored by check the inpoolUsage metric, when it is 1, it may have some problem. But when i check the inpoolUsage and inpoolQueueLength, I found the inconsistent problem. Although the inpoolUsage is calculated by bestEffotGetUsedBuffer / allbuffers, Is this lead to the mistake ? -- Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/
