hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: HTTP1.1 persistent connections
Date Tue, 16 Nov 2004 09:27:31 GMT
On Tue, 2004-11-16 at 07:15 +0100, Vjeran Marcinko wrote:
> Hi.
> I'm using version 2.0.2. Can someone explain me how does HttpClient
> handle
> (timeouted) HTTP1.1 persistent connections ?
> Story goes like this : HttpClient makes HTTP request to some remote
> Tomcat
> where server's response doesn't contain "Connection: close" header,
> thus
> connection is stored in pool for later reuse, in other words,
> connection
> keeps being established. As most of the HTTP servers, Tomcat has
> timeout on
> connections (default 20 secs), and closes the connection afterwards
> since
> let's assume it hasn't been used in the mean time. Connection goes
> into
> FIN_WAIT_2 state on Tomcat side, and CLOSE_WAIT on client side since
> client
> doesn't know connection has been closed (needless to say that both of
> these
> states are dangerous). SO, what happens when client wants to perform
> another
> HTTP request to this Tomcat, and reuse this connection. How does it
> realize
> it has been closed by server ? Does it dispose it ?

This is an inherent Java problem as there's no reliable way (I/we know
of) to find out the state of an open socket save performing an I/O
operation on it.

Both HttpClient 2.0 and 3.0 will perform a so called 'stale' connection
check prior to reusing the connection to work the problem around. If the
connection is found to be stale connection it will be dropped and a new
connection will be established. In HttpClinent 3.0 one can also
implement a custom idle connections eviction mechanism   

> And one more question, is there some way to force HttpClient to close
> connection after each request, regardless of server's response
> (meaning
> Connection header) ? I'm asking this because there are some stupid
> servers out there that don't respond me with "Connection: close" that
> would
> close it, although my HttpClient sends this same header in request....
> :-(
The best way of ensuring connection closure is to implement a custom
connection manager which would force-close upon release 




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

View raw message