- Create AbstractBackoff class as a base for different backoff strategies
- Add LinearBackoffManager class for implementing linear backoff algorithm in networking and communication systems. This class provides a thread-safe and configurable implementation of linear backoff, allowing for gradual adjustment of maximum connection pool sizes for a given route based on traffic and other factors. The class supports customizable cool-down periods and increment values for each route, and uses a ConcurrentHashMap to ensure thread safety and accurate tracking of backoff and probe attempts
- Implement ExponentialBackoffManager for connection pool control.
This commit introduces the ExponentialBackoffManager class, which manages the connection pool control for HTTP routes based on the Exponential Backoff algorithm. This implementation helps improve connection handling and stability in case of connection failures or network issues.
In this commit, we have made several improvements to the AIMDBackoffManager class:
* Replaced volatile variables with AtomicReference and AtomicInteger to ensure better thread-safety and atomic operations.
* Updated the @Contract annotation to reflect the new thread-safe behavior of the class.
* Added parameter validation checks to public methods for better error handling and prevention of incorrect usage.
* Improved the code readability and organization by separating sections of the class with blank lines and consistent indentation.
* These enhancements make the AIMDBackoffManager class more robust, reliable, and easier to maintain.
This change modifies the NTCredentials class to determine the local workstation name at runtime or request time, in line with the underlying NTLM implementation. The deprecated constructor with the workstation parameter is replaced with a new constructor that does not require the workstation parameter. Instead, it automatically retrieves the workstation name using the getWorkstationName() method.
This commit introduces the DistributedProxySelector class, which enables efficient and thread-safe proxy selection among multiple ProxySelector instances. The new class ensures proper distribution of proxy selector usage with the help of AtomicInteger and maintains thread safety using ThreadLocal.
Key features and improvements:
Distributes proxy selection among multiple ProxySelector instances
Ensures thread safety by using ThreadLocal<ProxySelector>
Properly handles exceptions and connection failures
Comprehensive JavaDoc documentation for class, methods, and variables
Includes unit tests for various scenarios and edge cases
This new functionality provides a robust and efficient solution for distributing proxy selection in multi-threaded environments, improving the overall performance and reliability of the system.
Previously, multipart entities did not support adding a preamble or epilogue to the message. This commit adds support for these features by modifying the AbstractMultipartFormat class to accept preamble and epilogue strings in its constructor. The HttpRFC6532Multipart, HttpRFC7578Multipart, and HttpStrictMultipart classes are updated to pass these parameters to the parent constructor when creating instances of multipart entities.
This change allows users to include custom content at the beginning and end of their multipart messages, which can be useful in certain scenarios such as adding metadata or information about the message contents.
This commit enhances the `ContentResponseHandler` class to be more fault-tolerant by handling responses with null or empty bodies without throwing exceptions. If the response was successful (a 2xx status code), the `Content` object is returned. If no response body exists, `Content.NO_CONTENT` is returned.
The implementation extends `ContentResponseHandler` and overrides its methods to handle the response entity and transform it into the actual response object. This is designed to be efficient and use minimal memory.
For digest authentication, in RFC 7616 section "3.4 The Authorization
Header Field":
The values of the opaque and algorithm fields must be those supplied
in the WWW-Authenticate response header field for the entity being
requested.
This commit honors that rule, and removes the previous behavior that
augmented the request header with "algorithm=MD5" when none was provided
in the server's response.
Aside from the specification, it also stands to reason that if the
server failed to provide "algorithm=..." in its "WWW-Authenticate"
header, the server should be fine with the client failing to provide
"algorithm=..." in the "Authorization" header.
The motivation for this change is that including "algorithm=MD5" in the
"Authorization" header causes http requests to fail when made to an
embedded system, which I suspect to be a an Espressif ESP32 web server.
Arturo Bernal
Oleg Kalnichevski
Christoph Kaser
John Vasileff
Gary Gregory
Gary Gregory
dependabot[bot]
Oleg Kalnichevski
Michael Lee
Alice Li
Siva Kumar Edupuganti
MartinWitt
Alen Turkovic
Damiano Albani
Bryan Keller