Mailing-List: contact httpclient-users-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-users@hc.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Date: Thu, 30 Jul 2009 12:07:56 +0200
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpClient User Discussion <httpclient-users@hc.apache.org>
Subject: Re: CLOSE_WAIT on Linux
Message-ID: <20090730100756.GA9489@ok2cons2.nine.ch>
Mail-Followup-To: HttpClient User Discussion <httpclient-users@hc.apache.org>
References: <5398EA15EAA90D4594C057180504F6030423961CCB@LAWMB-EX.soa.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5398EA15EAA90D4594C057180504F6030423961CCB@LAWMB-EX.soa.local>
User-Agent: Mutt/1.5.18 (2008-05-17)

On Wed, Jul 29, 2009 at 09:36:20PM -0700, Gerry Woods wrote:
> I haven't posted here before so let me start by thanking you guys for the great work.
> 
> We are using 3.0.1 in some pretty heavy production environments.   A recent issue arose with a customer who had trouble during SSL handshakes.  The negotiation was timing out:
> 
>  [120009] java.net.SocketTimeoutException: Read timed out
>                 at java.net.SocketInputStream.socketRead0(Native Method)
>                 at java.net.SocketInputStream.read(Unknown Source)
>                 at com.sun.net.ssl.internal.ssl.InputRecord.a(Unknown Source)
>                 at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source)
>                 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Unknown Source)
>                 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(Unknown Source)
>                 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Unknown Source)
>                 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
>                 ...
> 
> We're setting SO_TIMEOUT to 2 minutes.  The customer reports that the machine that initiated the connection ended up with a lot of sockets in CLOSE_WAIT.  From what I've been able to glean from some quick searches, it sounds like on some socket stacks, a shutdownOutput is required, and that close() is not enough to nudge the socket from CLOSE_WAIT to LAST_ACK.  I notice that in the 4.x codebase, shutdownOutput is being used, but in the 3.x code it is not.  Can anyone confirm that this is indeed the case for Linux?  If so, is there a known workaround other than upgrading to 4.x?
> 
> Thanks for any help you can offer, and thanks again for all the countless hours (and dollars!) your efforts have saved us.
> 
>

Gerry,

As far as I know SO_TIMEOUT parameter and CLOSE_WAIT socket state are
completely unrelated. Usually sockets end up in the CLOSE_WAIT state when a
persistent connection is closed by the remote server while still kept alive in
the connection pool on the client. This is general problem with the blocking
I/O model and both HttpClient 3.x and 4.0 are affected by it. However,
HttpClient 4.0 is much better equipped to deal with the issue. In both cases
one needs to implement some sort of connection eviction policy to make sure
that persistent connections that have been idle for too long get closed and
evicted from the pool.

http://hc.apache.org/httpcomponents-client/tutorial/html/ch02.html#d4e638

Hope this helps

Oleg

 

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