Ok cool. I will propose a PR. Chris
On Sun, Nov 10, 2019 at 6:40 AM Oleg Kalnichevski <[email protected]> wrote: > On Fri, 2019-11-08 at 13:09 -0800, Chris Wildman wrote: > > Hi HC Dev, > > > > I'm investigating lock contention issues when using the > > PoolingHttpClientConnectionManager, similar to those described in > > https://issues.apache.org/jira/browse/HTTPCLIENT-1809. > > > > I noticed in the older AbstractConnPool and the latest StrictConnPool > > is > > that when leasing a connection the connection request timeout is not > > used > > in the attempt to acquire the global lock. See: > > > > https://github.com/apache/httpcomponents-core/blob/master/httpcore5/src/main/java/org/apache/hc/core5/pool/StrictConnPool.java#L175 > > > > It seems to me the time spent acquiring this lock does count against > > the > > total connection request time and therefore should be using the > > timeout > > value. It can be misleading to have a connection request take longer > > than > > your timeout value (due to lock contention) but not actually timeout. > > Catching this specific timeout would also create the opportunity for > > additional stats/signaling that you're dealing with contention on > > that lock. > > > > Thoughts? > > > > Thanks, > > Chris > > Hi Chris > > I think it would make sense to fail connection requests if the pool > lock cannot be acquired within `requestTimeout` time span. > > Feel free to propose a PR at Github. > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
