Hi Brian, You are correct in your understanding about exceptions that are not caught by the processor.
Part of rolling back the session is putting the flow file back in the queue where it came from, so the flow file will remain in the queue before the processor and will continue to be submitted to the processor, but of course the processor will yield which will slow it down a little bit. Generally the above behavior is what you want if something completely unexpected happens, but if there are specific error conditions that you know of then you likely want to handle these by catching those exceptions and routing to specific relationships. For example, when sending data to an external system one error might be because the data you sent is malformed and it will always fail, and another error might be because the service was down in which case it would work if you retried later. For this case you could have a failure relationship for the data failures, and connection_failure relationship for the failures when the system is down. Hope this helps. -Bryan On Sat, Mar 25, 2017 at 10:11 AM, Brian Jeltema <[email protected]> wrote: > I’m writing a customer processor, and I’m confused about error handling. As I > understand it, > if an Exception is thrown that is not handled by my processor, then it is > handled by the > framework by doing a session rollback and administrative yield. What I don’t > understand > it what happens to the original flowfile. Does it get resubmitted to the > processor? If so, > and the Exception keeps being thrown, what ultimately happens to the flowfile? > > Thanks in advance > Brian
