You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Peter Gyori (Jira)" <ji...@apache.org> on 2021/02/17 16:41:00 UTC

[jira] [Assigned] (NIFI-8207) Counters in the Wait/Notify pattern do not work as expected

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

Peter Gyori reassigned NIFI-8207:
---------------------------------

    Assignee: Peter Gyori

> Counters in the Wait/Notify pattern do not work as expected
> -----------------------------------------------------------
>
>                 Key: NIFI-8207
>                 URL: https://issues.apache.org/jira/browse/NIFI-8207
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Extensions
>            Reporter: Peter Gyori
>            Assignee: Peter Gyori
>            Priority: Major
>              Labels: Wait/Notify
>
> The counters in the Wait/Notify pattern do not work as expected, the way counters are decremented seems to be wrong.
> A simple example to reproduce the issue:
> Let's use only one cache, identified by Release Signal ID "A".
> 1) Send 2 signals to cache "A", both with counter named "counter_1".
> 2) Also send 1 signal to cache "A" with counter named "counter_2".
> At this state, the cache looks like this:
> counter_1 -> 2
> counter_2 -> 1
> If we send 1 flowfile to the corresponding Wait processor, that looks for "counter_1" in cache "A", after the flowfile passes the Wait processor, the value of "counter_1" gets decremented to 0 instead of 1.
> It can be checked in debug mode. It can also be checked on the UI by sending another flowfile to the Wait processor and checking the value of the counter attributes that get appended to it.
> The problem seems to come from this line in the WaitNotifyProtocol class:
> {color:#000080}final long {color}reducedSignalCount = signalCount % requiredCountForPass;



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