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.