You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Chris Wildman <cw...@newrelic.com.INVALID> on 2019/11/08 21:09:54 UTC
StrictConnPool timeout on lock during lease
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
Re: StrictConnPool timeout on lock during lease
Posted by Chris Wildman <cw...@newrelic.com.INVALID>.
Ok cool. I will propose a PR.
Chris
On Sun, Nov 10, 2019 at 6:40 AM Oleg Kalnichevski <ol...@apache.org> 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
Re: StrictConnPool timeout on lock during lease
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org