Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Tue, 15 Apr 2014 17:23:14 +0000 (UTC)
From: "Dmitry Potapov (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12708563.1397582500100.118600.1397582594869@arcas>
In-Reply-To: <JIRA.12708563.1397582500100@arcas>
References: <JIRA.12708563.1397582500100@arcas>
Subject: [jira] [Created] (HTTPCORE-378) AbstractConnPool should perform
 expired entries clean up outside of lock
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Dmitry Potapov created HTTPCORE-378:
---------------------------------------

             Summary: AbstractConnPool should perform expired entries clean up outside of lock
                 Key: HTTPCORE-378
                 URL: https://issues.apache.org/jira/browse/HTTPCORE-378
             Project: HttpComponents HttpCore
          Issue Type: Bug
          Components: HttpCore
    Affects Versions: 4.3.2
            Reporter: Dmitry Potapov
            Priority: Trivial


Currently expired entries are closed at AbstractConnPool.getPoolEntryBlocking:230. If connections have non-zero SO_LINGER enabled this will cause other threads to wait up to SO_LINGER seconds.
Unfortunately same reentrant lock is already held by PoolEntryFuture.get(), so list of pool entries to be closed must be accumulated but some external queue and processed by additional thread.

There is workaround for this issue for http-clients: apply patches from HTTPCORE-377 and HTTPCLIENT-1497 and set SocketConfig.setSoLinger(0).

Since this issue has workaround, I suggest to consider this issue as very low priority one.


--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org