Exceptions within the Processor
During the execution of the onTrigger
method of a Processor, many
things can potentially go awry. Common failure conditions include:
Incoming data is not in the expected format.
Network connections to external services fail.
Reading or writing data to a disk fails.
There is a bug in the Processor or a dependent library.
Any of these conditions can result in an Exception being thrown from the Processor. From
the framework perspective, there are two types of Exceptions that can escape a Processor:
ProcessException
and all others.
If a ProcessException is thrown from the Processor, the framework will assume that this is a failure that is a known outcome. Moreover, it is a condition where attempting to process the data again later may be successful. As a result, the framework will roll back the session that was being processed and penalize the FlowFiles that were being processed.
If any other Exception escapes the Processor, though, the framework will assume that it
is a failure that was not taken into account by the developer. In this case, the framework
will also roll back the session and penalize the FlowFiles. However, in this case, we can
get into some very problematic cases. For example, the Processor may be in a bad state and
may continually run, depleting system resources, without providing any useful work. This is
fairly common, for instance, when a NullPointerException is thrown continually. In order to
avoid this case, if an Exception other than ProcessException is able to escape the
Processor's onTrigger
method, the framework will also
"Administratively Yield" the Processor. This means that the Processor will not be
triggered to run again for some amount of time. The amount of time is configured in the
nifi.properties
file but is 10 seconds by default.