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 16:54:19 +0000 (UTC)
From: "Dmitry Potapov (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12708551.1397580772673.118392.1397580859576@arcas>
In-Reply-To: <JIRA.12708551.1397580772673@arcas>
References: <JIRA.12708551.1397580772673@arcas>
Subject: [jira] [Updated] (HTTPCLIENT-1497) Allow to enable SO_LINGER option
 with zero timeout
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HTTPCLIENT-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitry Potapov updated HTTPCLIENT-1497:
---------------------------------------

    Attachment: httpclient-enable-linger.patch

Please, consider attached patch as a fix for this issue

> Allow to enable SO_LINGER option with zero timeout
> --------------------------------------------------
>
>                 Key: HTTPCLIENT-1497
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1497
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>    Affects Versions: 4.3.3
>            Reporter: Dmitry Potapov
>         Attachments: httpclient-enable-linger.patch
>
>
> According to http://docs.oracle.com/javase/8/docs/api/java/net/StandardSocketOptions.html#SO_LINGER linger option is disabled by default. Currently if SocketConfig.soLinger is set to zero (default value is -1), then Socket.setSoLinger(false, 0) will be called, so linger will be disabled, which is undesirable. Zero SO_LINGER timeout is the essential feature for HttpClient, without it we will fall into one of two options:
> 1. With disabled SO_LINGER all system sockets can fall into TIME_WAIT status and client will stuck
> 2. With enabled non-zero SO_LINGER client will wait up to 1 second at AbstractConnPool.getPoolEntryBlocking (Line 230) while closing expired connections under lock (this lock is already held by PoolingEntryFuture.get(), so there is no quick fix to release this lock for other threads)
> I had encountered both of these issues on live systems.
> I understand that this change will break backward compatibility of config interpretation, but can we have this in 4.4?


--
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