Github user markap14 commented on the issue:
https://github.com/apache/nifi/pull/3131
@patricker you're right - it may perform just fine. However, the concern is
not that we are holding a lock longer but rather that we are obtaining it twice
as often now when there's data queued. The acquisition of the lock itself can
be expensive. So all I am suggesting is that we don't want to make such a
change without knowing how it's going to affect things. We'd want to gather
some performance numbers before and after this changeset is applied.
Specifically, I'd want to setup a test suite that calculates things like:
How long does it take to check if there are FlowFiles queued 10 million
times when there are no FlowFiles queued?
How long does it take to check if there are FlowFiles queued 10 million
times when there are FlowFiles queued?
How do these numbers change when you have 1 thread vs. 2 threads vs. 12
threads vs. 25 threads?
I'd want to run these tests 10-20 times in a row to ensure that the numbers
are steady, and then get these numbers before and after the changeset is
applied.
If the worst-case differs by say 5% then it's probably fine. If the worse
case differs by say 50% then it probably makes sense to look for a different
solution.
---
