Aldrin Piri created NIFI-1168:
---------------------------------
Summary: @TriggerWhenEmpty docs and developer guide incompatible
onTrigger definitions
Key: NIFI-1168
URL: https://issues.apache.org/jira/browse/NIFI-1168
Project: Apache NiFi
Issue Type: Bug
Components: Core Framework, Documentation & Website
Affects Versions: 0.3.0
Reporter: Aldrin Piri
The TriggerWhenEmpty javadoc has the following specification for when a
processor is executed:
{code}
/**
* 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.
*
*/
{code}
The developer guide, however specifies that:
{quote}
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
{quote}
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
