pvillard31 commented on PR #11708: URL: https://github.com/apache/nifi/pull/11708#issuecomment-5835203410
From a code review process PoV, it should be two separate PRs. If you have a PR to limit the number of commits being retrieved, this can be merged today, no issue on that. What I really want to understand is: in your environment, is limiting the number of commits we retrieve (we limited it to 10 in the Github client) not enough to solve your issue? I am asking because the change we made for the Github registry client made a huge difference in large scale deployments. Also, there is the option to now define the frequency at which the client is going to check the status for a given versioned process group. So the combination of both should significantly change the pressure on the git provider. I'm trying to understand why/what is missing to also need the caching approach that you are suggesting. If this is indeed required, then I feel like we should think of a way to have it without exposing a property for it. -- 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]
