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