Brandon DeVries created NIFI-3567:
-------------------------------------
Summary: CompoundUpdateMonitor logic flaw
Key: NIFI-3567
URL: https://issues.apache.org/jira/browse/NIFI-3567
Project: Apache NiFi
Issue Type: Bug
Affects Versions: 1.1.1, 0.7.1
Reporter: Brandon DeVries
Priority: Minor
The CompoundUpdateMonitor seems to be fundamentally flawed. When getting it's
state, it returns a DeferedMonitorAction\[1]. This "lazily" loads the state of
the monitors it has compounded, essentially meaning the state is calculated
when equals() is called\[2]\[3].
In other words, the state isn't calculated until you're comparing the state to
a new state... at which point the states will evaluate the same. If the file
hasn't actually changed, the state is now actually (at least partially) loaded,
so a file change going forward will be detected. However, if a new file comes
in before equals() has been called the change will not be detected.
As CompoundUpdateMonitor doesn't appear to actually be used in Apache NiFi, I
would suggest deprecating it, and removing in a future version. If a need for
this functionality is present now or in the future, I'd recommend creating
something such as a BooleanAndUpdateMonitor and BooleanOrUpdateMonitor,
allowing developers to compose whatever behavior they want (instead of the
forced AND logic of the CompoundUpdateMonitor). At the very least, the
DeferedMonitorAction needs to be eliminated.
\[1]
https://github.com/apache/nifi/blob/rel/nifi-0.7.1/nifi-commons/nifi-utils/src/main/java/org/apache/nifi/util/file/monitor/CompoundUpdateMonitor.java#L40-L43
\[2]https://github.com/apache/nifi/blob/rel/nifi-0.7.1/nifi-commons/nifi-utils/src/main/java/org/apache/nifi/util/file/monitor/CompoundUpdateMonitor.java#L87-L88
\[3]
https://github.com/apache/nifi/blob/rel/nifi-0.7.1/nifi-commons/nifi-utils/src/main/java/org/apache/nifi/util/file/monitor/CompoundUpdateMonitor.java#L64-L70
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
