In this case, is "configuration of pool" (I guess you mean like sizes etc) really needed? Would "use pool" (on/off) enough instead?
T On Mon, Mar 27, 2023 at 10:54 AM Michael Vitz <vitz.mich...@googlemail.com.invalid> wrote: > Yes, it seems the isStale-Implementation of BHttpConnectionBase > > ``` > @Override > public boolean isStale() throws IOException { > if (!isOpen()) { > return true; > } > try { > final int bytesRead = > fillInputBuffer(Timeout.ofMilliseconds(1)); > return bytesRead < 0; > } catch (final SocketTimeoutException ex) { > return false; > } catch (final SocketException ex) { > return true; > } > } > ``` > > does not work correctly with the way Azure intercepts these connections. > > What's the way to improve the situation? Opening a bug there and waiting > for it to be fixed? Or is the option to allow configuration of the pool, > TTL and or Disabling the pool, like wagon did feasible? > > Am Mo., 27. März 2023 um 09:58 Uhr schrieb Konrad Windszus < > konra...@gmx.de > >: > > > 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 > > >> > > >