[
https://issues.apache.org/jira/browse/NIFI-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980820#comment-15980820
]
ASF GitHub Bot commented on NIFI-3415:
--------------------------------------
Github user ijokarumawak commented on the issue:
https://github.com/apache/nifi/pull/1658
@mattyb149 Thanks for catching that! Your expectation was correct, however
AbstractProcessor always penalizes FlowFiles being processed when it rollback a
process session. The 2nd FlowFile was penalized and the 3rd one was processed
before the 2nd.
I updated processors using RollbackOnFailure to not extend
AbstractProcessor, so that those can penalize FlowFiles based on whether
RollbackOnFailure is enabled or not.
I confirmed that if the 2nd FlowFile failed out of 3 FlowFiles, the 2nd and
3rd FlowFiles stay in the incoming relationship and the 2nd FlowFile will be
processed again and again until it gets processed successfully.
Thanks again for your insightful review comments!
> Add "Rollback on Failure" property to PutHiveStreaming, PutHiveQL, and PutSQL
> -----------------------------------------------------------------------------
>
> Key: NIFI-3415
> URL: https://issues.apache.org/jira/browse/NIFI-3415
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Matt Burgess
> Assignee: Koji Kawamura
>
> Many Put processors (such as PutHiveStreaming, PutHiveQL, and PutSQL) offer
> "failure" and "retry" relationships for flow files that cannot be processed,
> perhaps due to issues with the external system or other errors.
> However there are use cases where if a Put fails, then no other flow files
> should be processed until the issue(s) have been resolved. This should be
> configurable for said processors, to enable both the current behavior and a
> "stop on failure" type of behavior.
> I propose a property be added to the Put processors (at a minimum the
> PutHiveStreaming, PutHiveQL, and PutSQL processors) called "Rollback on
> Failure", which offers true or false values. If set to true, then the
> "failure" and "retry" relationships should be removed from the processor
> instance, and if set to false, those relationships should be offered.
> If Rollback on Failure is false, then the processor should continue to behave
> as it has. If set to true, then if any error occurs while processing a flow
> file, the session should be rolled back rather than transferring the flow
> file to some error-handling relationship.
> It may also be the case that if Rollback on Failure is true, then the
> incoming connection must use a FIFO Prioritizer, but I'm not positive. The
> documentation should be updated to include any such requirements.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
