pspiller commented on PR #7532: URL: https://github.com/apache/nifi/pull/7532#issuecomment-1659551032
Thanks for the feedback! I did base InvokeHTTPRecord quite heavily on InvokeHTTP, so if that's not a good example to follow then I can understand that changes are required. I can definitely see the value in using `WebClientServiceProvider` - that would remove a number of config properties from InvokeHTTPRecord, as well as making the code easier to test. Having the retry handling and record splitting all inside the one processor does feel a bit like it's going against Nifi's default philosophy (break tasks up into multiple simple processors). My first instinct when building a flow was to split up the input records into individual FlowFiles and then handle HTTP requests individually. Synchronising and reassembling everything at the end got pretty painful, though, especially handling retries. The current InvokeHTTPRecord approach was largely copied from processors like LookupRecord (i.e. do the same operation for each record in the FlowFile). I could remove the record splitting logic from InvokeHTTPRecord and let splitting be handled later by a separate SplitRecord processor, if that'd be cleaner. I can write up an outline of how I see the processor working on the Jira issue, if that's the best way to move forward. -- 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: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
