[
https://issues.apache.org/jira/browse/NIFI-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503845#comment-16503845
]
ASF GitHub Bot commented on NIFI-5274:
--------------------------------------
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/2767
With the changes made it isn't really a recommended way to do it. What the
change does is look for specific runtime exceptions that the framework could
throw and which the user code of this processor couldn't really do anything
meaningful and causes the normal behavior that will happen if these exceptions
leak out which is yield/rollback. But that was done so that 'other' exceptions
besides those could then be handled in a way specific to what is desired here
and that is to treat the flowfile as a failure and route it appropriately.
Typically, you'd not want to be treating general exceptions as the reason for
'failure' routing and instead you'd be looking for specific conditions. So the
change here I think is just dealing with the reality of the limited options
this processor must have (i didnt' look into the details but that is what makes
sense to me).
> ReplaceText can product StackOverflowError which causes admin yield
> -------------------------------------------------------------------
>
> Key: NIFI-5274
> URL: https://issues.apache.org/jira/browse/NIFI-5274
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 1.6.0
> Reporter: Michael Moser
> Assignee: Michael Moser
> Priority: Major
>
> Regex Replace mode can easily produce StackOverflowError. Certain regular
> expressions are implemented using recursion, which when used on large input
> text can cause StackOverflowError. This causes the ReplaceText processor to
> rollback and admin yield, which causes the input flowfile to get stuck in the
> input queue.
> We should be able to catch this condition and route the flowfile to failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
