rjgoyln commented on PR #11175: URL: https://github.com/apache/ozone/pull/11175#issuecomment-5751954964
Thanks for pointing this out. I went through the job log, and the retry setting is taking effect, but it is not enough to overcome the sustained 429s. The step spent **276.7s** before failing. With `count=10` and the default 5s interval, that matches the expected 275s of linear backoff plus request time; without the setting, it would have failed after ~32s with the default `count=3`. I also found that the recurring issue is upstream of the retries: PRs that change `pom.xml` cannot get an exact Maven cache hit, so each job falls back to an older cache and fetches the delta from Central independently. Multiple Maven bump PRs running concurrently can amplify this. For the retry settings, I think we overshot a bit. Sonatype recommends not retrying 429s more aggressively, and NiFi/Hudi use `count=5` with `connectionMaxTtl` around 25–30s. We also currently have no `intervalMax`, so a large `Retry-After` could make the retry wait excessively long. I’d suggest: * reduce `count` to 5 * add `connectionMaxTtl=25` and an `intervalMax` * remove the ineffective `-Dhttp.keepAlive=false` * address the Maven cache separately to reduce requests to Central Ratis also adopted similar settings in RATIS-2698, so it may be worth keeping that in sync. WDYT? -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
