Thanks for the reproducer and sorry for not reading thoroughly before. Indeed the connection pool is not configurable yet with the native connector. According to https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/impl/conn/PoolingHttpClientConnectionManager.html stale connections are checked after 2 seconds before being reused but probably the check does not work for some reason with Azure….
> Am 27.03.2023 um 09:49 schrieb Michael Vitz > <vitz.mich...@googlemail.com.invalid>: > > 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 >>
