Github user mattyb149 commented on the issue:
https://github.com/apache/nifi/pull/2767
+1 LGTM, thanks to all for the reviews, and thanks Mike for the
improvement! Merging to master
---
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
Github user mattyb149 commented on the issue:
https://github.com/apache/nifi/pull/2767
I'm having trouble following the above conversation: why doesn't the
penalize apply here? I can't remember the default prioritizer but I'd think in
general we wouldn't want to have a large file clog
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/2767
Yeah, but there's only 1 other processor in the codebase that does data
transformation and does penalize on failure. By far most processors that
penalize on failure are ingress/egress processors, whe
Github user joewitt commented on the issue:
https://github.com/apache/nifi/pull/2767
@mosermw nah its ok - you're probably right
---
Github user ottobackwards commented on the issue:
https://github.com/apache/nifi/pull/2767
Thanks for the info @mosermw
---
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/2767
One never knows how a dataflow manager will design their flow, so I was
just trying to cover all bases. I don't think a downstream consumer would
notice that the failure files were penalized, but if
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/2767
@ottobackwards This post is old but I think still applies. In general,
most regular expression engines use recursion for some things.
https://stackoverflow.com/questions/7509905/java-lang-stackover
Github user ottobackwards commented on the issue:
https://github.com/apache/nifi/pull/2767
Can you point out the recursive code you are referencing?
---
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/2767
The situation I'm trying to catch uses a regular expression that looks
legitimate, so can't be caught while validating configuration, but then blows
up when the input flowfile causes the Pattern match
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 sh
Github user mosermw commented on the issue:
https://github.com/apache/nifi/pull/2767
I'm not sure I understand what your suggestion is @joewitt. Would you
clarify for me? Should I code it to catch StackOverflowError, which is the use
case that I need to handle cleanly?
The code
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
Github user ottobackwards commented on the issue:
https://github.com/apache/nifi/pull/2767
mvn package -P contrib-check passes,
code looks good.
The question that comes to my mind is if this is following some
'recommended' way of handling these exceptions, and should that
14 matches
Mail list logo
