Greg, Whether the output goes to “nonzero status” or “output stream”, the original FlowFile should still be sent to the “original” relationship.
Now, if you set retries to say 3 for “nonzero status” and a FlowFile is routed to that relationship, what will happen is that the FlowFile is retried. Nothing is routed to “original” or to “nonzero status”. It then tries again. This time, let’s say it goes to “nonzero status” again. Adds it back to the input queue. It then tries a third time. If it goes to “nonzero status”, then the original FlowFile should still go to “original” and the result of the command goes to “nonzero status.” If it instead goes to “output stream” then the original FlowFiles goes to “original” and the result of the command goes to “output stream.” In either case, the contents going to the “original” relationship should be the incoming FlowFile, unmodified. Am I misunderstanding what you’re trying to achieve? Thanks -Mark > On Jul 20, 2022, at 5:37 PM, Gregory M. Foreman > <[email protected]> wrote: > > Mark: > > Thank you for the explanation, yes it helps. I made the changes and > everything worked with one exception: preserving the original content. The > non-zero status will replace the flowfile content with whatever came through > the output stream, so the original content is lost. When the file is > processed correctly, two flowfiles are created for the original and the > output stream relationships. Connecting the original to a routeonattribute > processor that inspects the execution.status code and traps original files > that are errors is an option. Are there any options besides using the second > processor? > > Thanks, > Greg > >> On Jul 20, 2022, at 9:22 AM, Mark Payne <[email protected]> wrote: >> >> Greg, >> >> You wouldn’t want to retry the “original” relationship. The processor has 3 >> relationships: original, output stream, and nonzero status. It should always >> send the incoming FlowFile to original. So if you retry that relationship >> you’ll always retry the flowfile, regardless of whether it was successful or >> not. >> >> Instead, you should retry the “nonzero status” relationship. If a FlowFIle >> is routed to this relationship, it will instead be re-queued and processed >> again. Nothing will go to original in this case, because the processing is >> atomic. >> >> But if a FlowFile is routed to the “output stream” relationship (because >> it’s not retried) the FlowFile will continue on normally. And the original >> FlowFile will go to ‘original’. >> >> Additionally, if all retries are completed and it still is routed to >> “nonzero status” then at that point, the FlowFile will go to “nonzero >> status” and the original will be transferred to whatever connection (if any) >> you have for the “original” relationship. >> >> Does that help? >> >> Thanks >> -Mark >> >>> On Jul 20, 2022, at 9:12 AM, Gregory M. Foreman >>> <[email protected]> wrote: >>> >>> Hello: >>> >>> The ExecuteStreamCommand processor has 3 relationships. To trap processing >>> failures, I capture flowfiles from the original relationship, inspect the >>> cmd exit status, and reroute to a RetryFlowFile processor if the exit >>> status is not 0. I wanted to see if this could be simplified with the new >>> retry feature in 1.16. When I enable retry on the original relationship >>> and execute a failing cmd, the flowfiles remain penalized in the previous >>> success queue, but never exit to the original relationship. Is this >>> scenario supposed to work as I have it setup? >>> >>> Thanks, >>> Greg >> >
