[
https://issues.apache.org/jira/browse/NIFI-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16512802#comment-16512802
]
ASF GitHub Bot commented on NIFI-5274:
--------------------------------------
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/2767
@mattyb149 I think the issue is whether there is a reasonable expectation
that a user would loop back a 'failure' relationship, and precedent set in
other similar processors. For example, I consider ReplaceText in the same
category as processors that modify content such as CompressContent,
UnpackContent, and EncryptContent. None of those processors penalize flowfiles
sent to failure. In those processors it's not reasonable to expect a failure
to correct itself, so it's not reasonable to loop back the failure
relationship. I just followed that precedent when modifying ReplaceText for
this PR.
> 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)
