v4.4.0

Add explicit cleanup for applications that create and retire many clusters within a long-lived registry (#32, #33).

After awaiting pool shutdown, call removeEmptyCluster(clusterKey) to forget that cluster and its settings. Active pools and unfinished disposal prevent removal. The method does not close resources or wait.

Ordinary shutdown continues retaining configuration for reuse. Explicit removal starts a fresh cluster on later registration; old selections cannot borrow from a replacement, and concurrent registrations cannot create orphan pools in a removed registry.

Existing APIs remain available. Java 8, Generic Object Pool 2.6.0 and the automatic module name org.bbottema.clusteredobjectpool are unchanged.

v4.3.0

• #31: selectPoolCandidates(...) captures a finite, immutable list of registered destinations without borrowing resources. It respects the configured load balancer; only the first candidate advances the shared selection position. A retired registration is never replaced silently in that list.
• ResourcePoolSelection.claimWithContext(...) continues an already-started acquisition without restarting its budget or losing its claim identity and cancellation control.

List<ResourcePoolSelection<String, Connection>> candidates =
    clusters.selectPoolCandidates(clusterKey);
for (ResourcePoolSelection<String, Connection> candidate : candidates) {
    // Inspect the destination before borrowing from this same registration.
    configureFor(candidate.getPoolKey());
}

Applications still own failure classification and any retry policy. Existing one-pool selection and claim APIs, Java 8 and module names remain supported. Uses Generic Object Pool 2.6.0.

v4.2.0

Select a registered pool before borrowing a resource, so your application can finish destination-specific work without holding one. #29

ResourcePoolSelection<String, Connection> selected =
    clusters.selectPoolFromCluster("outbound", options);
if (selected == null) {
    throw new TimeoutException("Timed out selecting a pool");
}
prepareForDestination(selected.getPoolKey()); // your application code
PoolableObject<Connection> connection = selected.claim(options);
// Check for timeout, then use and release/invalidate as before.

Selection reserves no capacity and remains tied to its original registration. Selection and acquisition each support cancellation and their own timeout budget; pass the remaining deadline when the whole operation must share one limit.

Existing combined claim methods remain unchanged. Java 8 support, Generic Object Pool 2.5.1 and JPMS module names are unchanged. Usage and lifecycle details.

v4.1.1

Updates the core dependency from Generic Object Pool 2.5.0 to 2.5.1, carrying the timeout-policy equality correction into Clustered Object Pool.

Creation-age and last-allocation expiration policies with matching thresholds or randomized bounds now remain distinct. Combined-policy sets retain both rules, and each policy keeps separate expiry state. Matching configurations of the same policy type remain equal.

This patch preserves the clustered APIs, Java 8 support and the automatic module names org.bbottema.clusteredobjectpool and org.bbottema.genericobjectpool.

Tracked in #27 and implemented in #28. Upstream fix: Generic Object Pool #24 and #25, released in 2.5.1.

v4.1.0

Cancellable cluster acquisition

Version 4.1.0 carries Generic Object Pool 2.5.0's opt-in cancellation and acquisition budget through keyed, load-balanced and matching claims (#25, #26).

ClaimControl control = new ClaimControl();
ClaimOptions options = ClaimOptions.withTimeout(30, TimeUnit.SECONDS)
    .withClaimControl(control);
clusters.claimResourceFromPool(resourceKey, options); // worker
// stop handler: control.requestCancellation();

The same running budget includes registration, selection, waiting and resource preparation. The cluster timeout can shorten it, never restart or extend it. Cancellation throws CancellationException; expiry returns null. A handed-off resource remains the borrower's responsibility.

Concurrent first claims share registration. Allocator factories and load-balancing callbacks run outside registry bookkeeping, and shutdown includes registrations still finishing. One failed pool no longer hides another pool's pending cleanup.

Existing methods, allocator factories, Java 8 and automatic module names remain supported. Load balancing still selects one pool without failover. Running application callbacks must cooperate; cancellation cannot forcibly stop arbitrary code.

v4.0.4

#22: callers already waiting for a resource now recover after invalidation frees capacity, through generic-object-pool 2.4.3; public APIs and Java 8 compatibility are unchanged.

v4.0.3

Stable JPMS module identities

Version 4.0.3 publishes clustered-object-pool with the stable automatic module name org.bbottema.clusteredobjectpool and upgrades to generic-object-pool 2.4.2, whose stable name is org.bbottema.genericobjectpool. See #8 and commit 3c5682d.

Compatibility

The Java 8 bytecode/runtime baseline is unchanged. JPMS consumers should require the two stable module names above.

Original tag date: 2026-08-11.

v4.0.2

Complete draining-pool shutdown semantics

Version 4.0.2 removes retained draining-pool records once their shutdown futures complete and includes pools already draining in later matching or aggregate shutdown handles. It also upgrades to generic-object-pool 2.4.1 so completion waits for allocator cleanup callbacks. See #7 and commit 2b1131c.

Compatibility

No public signature changed. Shutdown completion is stronger and may finish later when physical cleanup is slow.

Original tag date: 2026-08-10.

v4.0.1

Cluster-specific pool configuration

Version 4.0.1 adds registerResourceCluster(...), allowing each cluster key to define its own core and maximum pool sizes, claim timeout, expiration policy, allocator factory, and load-balancing strategy while other clusters continue using global defaults. See #6 and commit 0e04c6e.

Compatibility

This is an additive API change on the 4.x allocator model.

Original tag date: 2026-07-07.

v4.0.0

Cluster-aware allocation and idle-resource maintenance

Version 4.0.0 passes the full typed ResourceKey<ClusterKey, PoolKey> to AllocatorFactory, allowing resource creation to use both cluster identity and pool identity (#1).

It also adds claimMatchingResourceFromPool(...) for selecting an already-idle resource by predicate without creating a pool or resource, enabling keep-alive and health workflows (#20).

Compatibility

This is a breaking allocator-factory API change: implementations must accept the full ResourceKey rather than only the pool key. The Java 8 baseline is retained. Matching predicates run under the pool claim lock and should remain fast.

Original tag date: 2026-07-05.