| commit | 775603ad19174b14eb7144cae15cd4be3956f702 | [log] [tgz] |
|---|---|---|
| author | Lari Hotari <lhotari@users.noreply.github.com> | Wed Nov 04 09:26:08 2020 +0200 |
| committer | GitHub <noreply@github.com> | Wed Nov 04 15:26:08 2020 +0800 |
| tree | cad210995a908a491f6c994020570b37f57e0d58 | |
| parent | 1c9839f1fb7c12c3d0f6e72c8397e4f404d8c7e0 [diff] |
Limit maven http connection pool TTL in Github flows (#2460) ### Motivation Fixes "Transfer failed for https://repo.maven.apache.org/... .jar: Connection reset" type of failures in Github Flows environment such as ``` Error: Failed to execute goal on project bookkeeper-common: Could not resolve dependencies for project org.apache.bookkeeper:bookkeeper-common:jar:4.12.0-SNAPSHOT: Could not transfer artifact org.jctools:jctools-core:jar:2.1.2 from/to central (https://repo.maven.apache.org/maven2): Transfer failed for https://repo.maven.apache.org/maven2/org/jctools/jctools-core/2.1.2/jctools-core-2.1.2.jar: Connection reset -> [Help 1] ``` ### Changes Set `maven.wagon.httpconnectionManager.ttlSeconds` to 25 seconds. Besides this, set `maven.wagon.http.retryHandler.count` to 3 retries. https://issues.apache.org/jira/browse/WAGON-545 contains a recommendation "Azure users shall set the TTL to 240 seconds or less." The reason for the 25 second TTL is to ensure that it's shorter than any common firewall or NAT timeout. Some NATs have a 30 second idle timeout although that is very rare. There shouldn't be harm in using the 25 second TTL since the connection pool will be able to pool connections well with a 25 second TTL. The documentation for `maven.wagon.httpconnectionManager.ttlSeconds` is available in the source code: https://github.com/apache/maven-wagon/blob/wagon-3.4.1/wagon-providers/wagon-http-shared/src/main/java/org/apache/maven/wagon/shared/http/AbstractHttpClientWagon.java#L297-L305 Documentation for `maven.wagon.http.retryHandler.count` is in https://maven.apache.org/wagon/wagon-providers/wagon-http/ "Any retry handler can only react to exceptions when executing the request and receiving the response head. It will not salvage in-flight failures of ongoing response body streams." Therefore the retry count setting is a bit different than expected. WAGON-545 explains that ConnectionExceptions aren't part of the retried exceptions by default. If such issues become problems, it's possible to configure the retry handler in a more fine grained way. This is similar to the change made in Pulsar: https://github.com/apache/pulsar/pull/8386
Apache BookKeeper is a scalable, fault tolerant and low latency storage service optimized for append-only workloads.
It is suitable for being used in following scenarios:
You can also read Turning Ledgers into Logs to learn how to turn ledgers into continuous log streams. If you are looking for a high level log stream API, you can checkout DistributedLog.
For filing bugs, suggesting improvements, or requesting new features, help us out by opening a Github issue or opening an Apache jira.
Subscribe or mail the user@bookkeeper.apache.org list - Ask questions, find answers, and also help other users.
Subscribe or mail the dev@bookkeeper.apache.org list - Join development discussions, propose new ideas and connect with contributors.
Join us on Slack - This is the most immediate way to connect with Apache BookKeeper committers and contributors.
We feel that a welcoming open community is important and welcome contributions.
See Developer Setup to get your local environment setup.
Take a look at our open issues: JIRA Issues Github Issues.
Review our coding style and follow our pull requests to learn about our conventions.
Make your changes according to our contribution guide.