On Fri, 2025-09-19 at 14:03 +0200, Arturo Bernal wrote: > OFFLOCK removes pool-wide lock contention on the disposal path and > isolates > contention per route. > Under slow closes or multi-route churn it keeps leasing non-blocking > via > direct handoff; LaxConnPool still serializes on shared structures and > stalls while closing. > Semantics match ManagedConnPool; it’s opt-in for users to benchmark. > > Arturo >
Hi Arturo The point I am trying to make is that if your proposed implementation is considerably better than LaxConnPool it should replace it because they both appear to share the same objective. However, there has to be some solid evidence of new implementation actually performing better and being better. Please do build a benchmark to measure performance of the exiting pool implementations and compare their performance to that of your new implementation. I also maintain a personal project that benchmarks Apache HttpClient against competing HTTP client implementations. What you may want to do is to fork the project and tweak it to run HttpClient 5 benchmarks with different connection pool implementations. Please consider it, but as I said earlier no one can stop you from contributing new features to the project. Oleg > > On Thu, Sep 18, 2025 at 9:26 PM Oleg Kalnichevski <[email protected]> > wrote: > > > > > > > On 9/18/2025 8:14 PM, Arturo Bernal wrote: > > > Hi all, > > > > > > To improve connection pool performance under high concurrency, I > > > propose > > > adding a new experimental lock-free pool implementation, > > > RouteSegmentedConnPool, to HttpCore 5.4. > > > > > > *Overview* > > > RouteSegmentedConnPool implements ManagedConnPool and introduces > > > a new > > > PoolConcurrencyPolicy.OFFLOCK. Its design: > > > > > > - > > > > > > Per-route segmentation (ConcurrentHashMap + > > > ConcurrentLinkedDeque) to > > > avoid global locks. > > > - > > > > > > Direct handoff to compatible waiters; otherwise reuse follows > > LIFO/FIFO > > > policy. > > > - > > > > > > Disposal handled off-lock via pluggable DisposalCallback to > > > ensure > > slow > > > closes don’t block unrelated routes. > > > - > > > > > > Preserves existing STRICT and LAX semantics; OFFLOCK is opt- > > > in. > > > > > > *API / Compatibility* > > > > > > - > > > > > > New PoolConcurrencyPolicy.OFFLOCK. > > > - > > > > > > PoolingHttpClientConnectionManager instantiates > > RouteSegmentedConnPool > > > when OFFLOCK is selected. > > > - > > > > > > No changes to existing defaults; backward compatibility is > > > preserved. > > > > > > The intent is to ship this as @Experimental in 5.4 so users can > > > benchmark > > > and provide feedback. > > > > > > Thoughts? > > > > > > Arturo > > > > > > > Arturo > > > > No one can stop you from contributing new features as long as you > > are > > willing to support them. > > > > In this very instance, however, how would this new pool > > implementation > > be better than LaxConnPool? > > > > Oleg > > > > ------------------------------------------------------------------- > > -- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
