You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Linton Miller (JIRA)" <ji...@apache.org> on 2019/07/27 20:37:00 UTC
[jira] [Updated] (HTTPCORE-586) LaxConnPool can do a better job of
maintaining pool size limits
[ https://issues.apache.org/jira/browse/HTTPCORE-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Linton Miller updated HTTPCORE-586:
-----------------------------------
Summary: LaxConnPool can do a better job of maintaining pool size limits (was: LaxConnPool can do a better job of maintain pool size limits)
> LaxConnPool can do a better job of maintaining pool size limits
> ---------------------------------------------------------------
>
> Key: HTTPCORE-586
> URL: https://issues.apache.org/jira/browse/HTTPCORE-586
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 5.0-beta8
> Reporter: Linton Miller
> Priority: Major
>
> LaxConnPool intentionally does not make strong guarantees about enforcing the maximum size of the connection pools. However, it has poor behaviour when hit with a block of concurrent requests all at once.
> e.g. if the pool max size is 2, and 20 lease request all arrive concurrently at once, it may well create 20 connections.
> That's because the pool size is limited by the leased size, but there's a gap in the code between testing the size and adding a leased entry:
> {code:java}
> if (pending.isEmpty() && leased.size() < max) {
> final PoolEntry<T, C> entry = new PoolEntry<>(route, timeToLive);
> addLeased(entry);
> {code}
> Thus multiple threads can concurrently pass the leased.size() < max test and thus all create a new PoolEntry.
> That can be greatly improved by not using the leased.size() to track pool size, but to have a separate explicit AtomicInteger counting the number of created PoolEntries.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org