rjgoyln opened a new pull request, #11175:
URL: https://github.com/apache/ozone/pull/11175

   ## Summary
   
   A pull request whose base predates a dependency bump on master restores a 
Maven cache built from newer poms, so the version it pins is absent and has to 
come from Central. When Central rate-limits that single request, the job fails 
during dependency resolution, before anything is compiled or any test runs.
   
   The retry settings in `MAVEN_OPTS` were meant to cover exactly this, and 
have not for some time. They configure Wagon, which stopped being the resolver 
transport when the runner image moved to Maven 3.9; dependencies now resolve 
through `maven-resolver-transport-http`, which reads 
`aether.connector.http.retryHandler.*`. An unread `-D` property is silently 
ignored, so the configuration kept looking correct while only the resolver's 
own default of three retries applied — about 30 seconds of patience, matching 
the 32 seconds from `Scanning for projects` to hard failure in the job linked 
from the JIRA.
   
   Using the property Maven actually reads raises per-artifact patience to 
roughly 275 seconds. The longest single wait stays at 50 seconds, below the 300 
second `intervalMax` beyond which the resolver abandons the retry rather than 
waiting, and every job already sets `timeout-minutes`, so a sustained outage 
still terminates. `maven.wagon.http.pool` goes for the same reason as the retry 
properties; `http.keepAlive` is JDK-level rather than Wagon's, so it stays.
   
   JIRA: https://issues.apache.org/jira/browse/HDDS-16359
   
   ## Tests
   
   Measured with Maven 3.9.16 — the runner image's version — against a 
repository that answers 429 to everything, counting requests server-side for 
one missing artifact:
   
   | `MAVEN_OPTS` | requests | elapsed |
   | --- | --- | --- |
   | (none) | 4 | 32s |
   | `-Dmaven.wagon.http.retryHandler.count=0` | 4 | 31s |
   | `-Daether.connector.http.retryHandler.count=0` | 1 | 4s |
   | `-Daether.connector.http.retryHandler.count=10` | 11 | 268s |
   
   Setting the Wagon count to zero changes nothing; setting the resolver count 
to zero takes effect immediately.
   
   ---
   
   Generated-by: Claude Code (Opus 5)
   


-- 
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]

Reply via email to