You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
7
7
8
8
## [Unreleased]
9
9
### Added
10
+
- Asynchronous API: `lookupAsync`/`parseAsync` methods on `IpregistryClient` return a `CompletableFuture` and are backed by a virtual-thread-per-task executor by default. The executor is configurable via `IpregistryConfig#executor` (a caller-provided executor is not shut down by the client).
10
11
- Support for a caller-provided `CloseableHttpClient` via new `IpregistryClient` and `DefaultRequestHandler` constructors, allowing full control over connection pooling, proxying, TLS, and metrics. An injected client is not closed by the Ipregistry client (the caller retains ownership).
11
12
- Typed error codes: `ApiException#getErrorCode()` (and `Error#getErrorCode()`) now return a strongly typed `ErrorCode` enum in addition to the raw string `code`, allowing callers to branch on error conditions without string matching. Unrecognized codes return `null` while the raw code remains available.
12
13
- Automatic retries with exponential backoff for transient network errors and 5xx server responses, configurable via `IpregistryConfig` (`retryMaxAttempts`, `retryInterval`, `retryOnServerError`, `retryOnTooManyRequests`). Retries on 429 Too Many Requests are disabled by default and honor the `Retry-After` header when enabled.
When you supply your own client, you own its lifecycle: it is **not** closed when the Ipregistry client is closed, and the timeout/retry settings from `IpregistryConfig` are ignored in favor of your client's own configuration.
177
177
178
+
## Asynchronous API
179
+
180
+
Every lookup and parse method has an asynchronous variant returning a `CompletableFuture`, suitable for composing non-blocking pipelines:
error.getCause().printStackTrace(); // ApiException or ClientException
189
+
returnnull;
190
+
});
191
+
```
192
+
193
+
The futures are backed by a virtual-thread-per-task executor (Java 21+), so thousands of concurrent lookups are cheap. A failed request completes the future exceptionally with the same `ApiException`/`ClientException` thrown by the synchronous API (wrapped in a `CompletionException`, so unwrap via `getCause()`).
194
+
195
+
To use your own executor, set it on the configuration. You then own its lifecycle: it is not shut down when the client is closed.
196
+
197
+
```java
198
+
IpregistryConfig config =
199
+
IpregistryConfig.builder()
200
+
.apiKey("YOUR_API_KEY")
201
+
.executor(myExecutorService)
202
+
.build();
203
+
```
204
+
205
+
Reactive users can bridge these futures directly, for example with `Mono.fromFuture(...)` (Reactor) or `Single.fromCompletionStage(...)` (RxJava).
206
+
178
207
## Errors
179
208
180
209
All Ipregistry exceptions inherit the _IpregistryException_ class.
0 commit comments