Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
0.3.0
-
None
Description
The TriggerWhenEmpty javadoc has the following specification for when a processor is executed:
/**
* Marker annotation a {@link org.apache.nifi.processor.Processor Processor}
* implementation can use to indicate that the Processor should still be
* triggered even when it has no data in its work queue. By default, Processors
* which have no non-self incoming edges will be triggered even if there is no
* work in its queue. However, Processors that have non-self incoming edges will
* only be triggered if they have work in their queue or they present this
* annotation.
*
*/
The developer guide, however specifies that:
A Processor’s onTrigger method will be called only when it is scheduled to run and when work exists for the Processor. Work is said to exist for a Processor if any of the following conditions is met:
A Connection whose destination is the Processor has at least one FlowFile in its queue
The Processors has no incoming Connections
The Processor is annotated with the @TriggerWhenEmpty annotation
The key difference is that TriggerWhenEmpty specifies that if a processor only has self-directed incoming edges/loops, it will still be triggered by the framework, while the Developer Guide seems to not make such provisions.
The behavior outlined in the developer guide is currently what is seen and this was stumbled upon while reviewing the patches associated with NIFI-1086 and introduces a unique case in terms of functionality. Given that an InvokeHTTP processor can be run with or without inputs, there are certain relationships that would never happen (like the retry or failure) when the processor is driven only by a trigger event. In this case, loops that were instinctually created while making a sample flow to retry requests prevented the processor from executing.