You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Joe Witt (Jira)" <ji...@apache.org> on 2023/04/05 17:33:00 UTC
[jira] [Commented] (NIFI-11388) Backpressure queue settings loosely followed
[ https://issues.apache.org/jira/browse/NIFI-11388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709030#comment-17709030 ]
Joe Witt commented on NIFI-11388:
---------------------------------
Hello
This is true and by design. It was never meant as a hard limit. The core reason is that we use this to prevent a processor from being scheduled if any possible destination is already full by default but we dont want to prevent it from completing its work once given threads/having a session.
I am pretty sure our documentation also speaks about this.
> Backpressure queue settings loosely followed
> --------------------------------------------
>
> Key: NIFI-11388
> URL: https://issues.apache.org/jira/browse/NIFI-11388
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Nissim Shiman
> Priority: Major
>
> The backpressure settings on connections between processors are only loosely followed. More flowfiles can end up on queues than configured via backpressure setting.
> For example, set up flow:
> GenerateFlowFile -> UpdateAttribute -> (some processor)
> where
> GenerateFlowFile has _Custom Text_ set to be _hello_
> and Run Schedule is set to be _0 min_
> and
> the connection following UpdateAttribute has _Back Pressure Object Threshold_ set to be _100_
> Start GenerateFlowFile.
> Wait a few moments until outgoing connection fills up.
> Start UpdateAttribute
> OutGoing conection will have more than 100 flowfiles on it
> (I had over 1000 on mine when running these steps)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)