Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/2767
My response was to the general pattern of how to handle exceptions/failure
routing.
Category1: For things you can anticipate and detect in the flowfile that
make processing not viable - we should ideally detect these and route to
failure as they'll never process nicely so yield/rollback isnt viable.
Category2:For things you can anticipate in flowfiles that will cause
processing problems but detection isn't viable/etc.. then relying on a specific
known set of exceptions is fair game. Route these to failure as yield/rollback
isn't viable and wont solve the problem.
Category3: If you know bad stuff can happen but cannot detect them ahead of
time and there isn't a clear finite set of things to detect then doing what
you're doing to isolate them by instead putting the frameworky things in a
finite set and calling all else as 'failure' is fair game.
Your case appears to be Category3 right now so you're handling it fine for
that. Ideally though you could try to move to Category 1 and if not then
fallback to Category2.
Again I'm really responding more to Otto's question about the
patterns/recommendations than what 'you did'. I didn't look into the details
of the options you had available to you and if indeed Category3 is as good as
it gets then I think you did the right thing here.
In this case my hope would be we could detect configurations or data
patterns that would lead to StackOverflowError and avoid that altogether but
i'm saying that without understanding the details of this case so please dont
take that too seriously.
Hopefully that makes more sense.
---
