greyp9 commented on PR #9445: URL: https://github.com/apache/nifi/pull/9445#issuecomment-2438611658
> Thanks @turcsanyip, that makes total sense and thanks @greyp9 for testing and discussions on the Slack thread. If we prefer to just use a synchronized list instead, I'm totally OK with this approach but, as I said before, I don't really see the value of maintaining successes and failures lists as we're not really doing anything with it (like logging number of failures vs number of successes, etc). > > If we prefer to maintain the current approach and change to a synchronized list, I do think a bit of reworking is still needed to expose the logs from FlowFileResult as processor level bulletins - right now, routing flow files to failure or retry would not trigger any bulletin. > > Happy to file another PR if that's the consensus. FlowFileResult / RelationshipMapper acquires the success messageID from the first success, and iterates through the failures to determine whether the FlowFile should be considered retryable. Other than that, it is true that the lists are mostly unused. It seems like a good idea that failure messages might be logged somehow, or that non-zero successCount / failureCount could be added as FlowFile attributes. I wish I had considered this during the original implementation. It is also a great idea to expose the FlowFileResult as processor level bulletins. Given the timing of this (pending releases), and depending on your availability, would you consider a two-phase approach here? I could put up a simple PR to synchronize the lists, which would prevent the hang. Given additional time, your reworked PR could implement additional logging and tracking to improve the user experience. Then again, a reworked PR might end up being simple enough to quickly turn around by itself. I'm open to your thoughts, and set up to test whatever you think best. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
