Thanks, Oleg — makes sense. I’ll fork your benchmark project and add a switch to compare Lax/Strict vs RouteSegmented (“OFFLOCK”) under the same scenarios.
Arturo On Fri, 19 Sep 2025 at 9:16 PM, Oleg Kalnichevski <[email protected]> wrote: > 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] > >
