Hi Konrad, The only two timeout related properties are aether.connector.requestTimeout and aether.connector.connectTimeout. Both do not solve my problem.
I created a GitHub project ( https://github.com/mvitz/maven-39-gh-actions-timeouts) which reproduces the problem. It declares many dependencies/plugins to make sure the complete HTTP pool is used before the tests, contains a test that runs in total about 6 minutes to take longer than the four-minute Azure timeout and uses Maven 3.9.1. The first build ( https://github.com/mvitz/maven-39-gh-actions-timeouts/actions/runs/4524745997/jobs/7968775993) uses -Daether.connector.requestTimeout=270000 which is longer than four minutes and fails. The second one ( https://github.com/mvitz/maven-39-gh-actions-timeouts/actions/runs/4524925829/jobs/7969075725) uses -Daether.connector.connectTimeout=60000 -Daether.connector.requestTimeout=180000 which is shorter but fails, too. Both builds fail with: Error: Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:3.3.0:jar (default-jar) on project maven-39-gh-actions-timeouts: Execution default-jar of goal org.apache.maven.plugins:maven-jar-plugin:3.3.0:jar failed: Plugin org.apache.maven.plugins:maven-jar-plugin:3.3.0 or one of its dependencies could not be resolved: Failed to collect dependencies at org.apache.maven.plugins:maven-jar-plugin:jar:3.3.0 -> org.apache.maven.shared:file-management:jar:3.1.0: Failed to read artifact descriptor for org.apache.maven.shared:file-management:jar:3.1.0: The following artifacts could not be resolved: org.apache.maven.shared:file-management:pom:3.1.0 (absent): Could not transfer artifact org.apache.maven.shared:file-management:pom:3.1.0 from/to central (https://repo.maven.apache.org/maven2): Read timed out -> [Help 1] I suspect that the HTTP pool is fully used before the tests, all connections are silently interrupted during the test run that takes longer than the Azure limit of four minutes, and the pool unable to recover any connection from that. As told before when using wagon with -Dmaven.resolver.transport=wagon and configuring a pool time to love of 3 minutes via -Dmaven.wagon.httpconnectionManager.ttlSeconds=180 everything works as expected ( https://github.com/mvitz/maven-39-gh-actions-timeouts/actions/runs/4529868249/jobs/7978093099 ). Regards, Michael Am So., 26. März 2023 um 12:54 Uhr schrieb Konrad Windszus <konra...@gmx.de >: > The timeouts are configurable even with new native connector: > https://maven.apache.org/resolver/configuration.html. > Please try if those settings help. > Konrad > > > Am 25.03.2023 um 15:08 schrieb Michael Vitz <vitz.mich...@googlemail.com > .invalid>: > > > > Hi all, > > > > We recently switched from Maven 3.8.x to 3.9.x and all of a sudden, we > ran > > into connection timeouts during downloading the maven-jar-plugin after > all > > tests passed. > > > > After some digging, I suspect that it is a combination of GitHub Actions > > running on Azure which silently drops open connections after around four > > minutes (see discussion in > > https://github.com/actions/runner-images/issues/1499) and the switch to > the > > native HTTP transport in Maven 3.9.x. > > Our tests take quite some time and because the maven-jar-plugin is > freshly > > downloaded after these, the used connection was opened before the tests > > were started and is dropped by Azure meanwhile. > > > > Our current workaround is switching to the old Wagon HTTP provider (with > > -Dmaven.resolver.transport=wagon) and setting a TTL for the used HTTP > pool > > (-Dmaven.wagon.httpconnectionManager.ttlSeconds=180) or disabling the > pool > > and keep alive (-Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false). > > > > Unfortunately, the new HTTP transport does not allow changing the TTL > > (which by default is -1 which means forever) or disabling it altogether. > It > > would be nice if such settings would be added in one of the next > releases. > > > > I would be happy to help/try to provide a patch on my own if this helps. > > > > Regards, > > Michael >
