CODEWITHSUNDEEP
javamaven
bercik
bercik

Reputation: 916

Maven retry dependency download if failed

During downloading dependencies by maven, one of it fails due to network issues:

Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-failsafe-plugin/2.16/maven-failsafe-plugin-2.16.pom
Plugin org.apache.maven.plugins:maven-failsafe-plugin:2.16 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-failsafe-plugin:jar:2.16

I would like to retry it for n times where n will be configurable. How can I do this?

Upvotes: 12

Views: 11653

Answers (5)

Lari Hotari
Lari Hotari

Reputation: 5310

In the case that you are running in an environment behind a NAT, with a short NAT timeout, one possibility is to set -Dmaven.wagon.httpconnectionManager.ttlSeconds=25 and -Daether.connector.http.connectionMaxTtl=25 (Maven 3.9+) instead of disabling the http connection pooling in maven.

This is used in apache/pulsar repository:

env:
  MAVEN_OPTS: -Dmaven.wagon.httpconnectionManager.ttlSeconds=25 -Dmaven.wagon.http.retryHandler.count=3 -Daether.connector.http.connectionMaxTtl=25

In the last comment of WAGON-545, it says "Azure users shall set the TTL to 240 seconds or less."

Upvotes: 5

Donal Fellows
Donal Fellows

Reputation: 137687

If this is in a long-ish build in a recent enough Maven (3.9 or later) and you're doing this because of a build on Azure (e.g., inside Github Actions using the standard runners) then you're hitting a problem with stale connections; there's a firewall in Azure that silently drops long-lived inactive connections, and anything idle for over half a minute or so is at risk from it. There are other solutions above, but they don't work because Maven now uses the Aether library for HTTP connections instead of Wagon.

The fix I've now got deployed in my code is to set a system property for the Java code with -Daether.connector.http.connectionMaxTtl=25. This seems to do the trick. (As you can see from looking through this page, Aether will retry connections three times by default. That isn't helpful inside Azure, but is in other situations.)

Within a Github Actions workflow, the easiest way of passing this in is via a top-level env setup in your workflow file so that it is applied to all calls to Maven:

env:
  MAVEN_OPTS: >
    -Daether.connector.http.connectionMaxTtl=25

(If you have other things you're putting into MAVEN_OPTS then you'll need to merge things. I find the above a good and readable way to do it, with one system property per line.)

Upvotes: 2

crenshaw-dev
crenshaw-dev

Reputation: 8382

I had a similar problem in Gitlab CI/CD. This seems to have resolved the issue:

-Dmaven.wagon.http.retryHandler.count=3

Since version 3.2, the retry handler can be configured with system properties:

...

    • maven.wagon.http.retryHandler.count = number of retries for default or standard implementations.

Other HTTP client settings are described here: https://maven.apache.org/wagon/wagon-providers/wagon-http/

Edit: As keiki pointed out in the comments, 3 appears to be the default, so it's not clear how setting this value would help. Please comment with your experience.

Upvotes: 12

rfreytag
rfreytag

Reputation: 1330

Maven seems to have an issue with fetching dependencies due to keep-alive connections being closed. This happens when you are running mvn in a build-environment (Docker, Azure, Jenkins) and the build is rather long (> 5 minutes).

Use this maven flag to disable keep-alive for HTTP requests and see if it fixes your problem:

-Dhttp.keepAlive=false

Others have mentioned using this flag as well:

-Dmaven.wagon.http.pool=false

For example

mvn -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false clean package

Source of the original solution for azure

Upvotes: 11

J Fabian Meier
J Fabian Meier

Reputation: 35843

Let me suggest an alternative solution:

Set up a Nexus or Artifactory server in your local network. Let your builds run through it. It will cache all the artifacts that were used so that the risk of running into network problems dramatically decreases.

Upvotes: 2

Related Questions