On Sat, 2025-09-20 at 07:09 +0200, Arturo Bernal wrote: > 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. > >
I just noticed you had a micro-benchmark included in your pull request. I guess this should be enough. Cheers Oleg > > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
