hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35944] - default CONNECTION_MANAGER_TIMEOUT should not be zero
Date Mon, 01 Aug 2005 14:13:58 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35944>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35944





------- Additional Comments From garry@ascii-turf.net  2005-08-01 16:13 -------

hey there.

ok. i think i'm getting a handle on this and maybe there is a more serious problem lurking
in the code... 
i might be wrong but bear with me.

the situation seems to be this:

i'm repeatedly connecting to the same server using a multi threaded connection manager which,

however, is only managing a single thread.

but, the server, or my connection, is unstable and goes down.

here's the tail of the log from the session in question:

=====================
...
07/30 01:18:12 DEBUG HttpMethodBase [5948 http://humboldt.craigslist.org:80/sfo/eby/  3] -
enter 
HttpMethodBase.readResponseBody(HttpConnection)
07/30 01:18:12 DEBUG HttpConnection [5948 http://humboldt.craigslist.org:80/sfo/eby/  3] -
enter 
HttpConnection.getResponseInputStream()
07/30 01:18:12 DEBUG HttpMethodBase [5948 http://humboldt.craigslist.org:80/sfo/eby/  3] -
enter 
HttpMethodBase.canResponseHaveBody(int)
07/30 01:18:12 DEBUG HttpConnection [5948 http://humboldt.craigslist.org:80/sfo/eby/  3] -
enter 
HttpConnection.close()
07/30 01:18:12 DEBUG HttpConnection [5948 http://humboldt.craigslist.org:80/sfo/eby/  3] -
enter 
HttpConnection.closeSockedAndStreams()
07/30 01:18:12 DEBUG HttpMethodBase [5948 http://humboldt.craigslist.org:80/sfo/eby/  3] -

Resorting to protocol version default close connection policy
07/30 01:18:12 DEBUG HttpMethodBase [5948 http://humboldt.craigslist.org:80/sfo/eby/  3] -
Should 
NOT close connection, using HTTP/1.1
07/30 01:18:12 DEBUG HttpConnection [5948 http://humboldt.craigslist.org:80/sfo/eby/  3] -
enter 
HttpConnection.isResponseAvailable()
07/30 01:18:14 DEBUG GetMethod [5948 http://humboldt.craigslist.org:80/sfo/eby/mis/  3] -
enter 
GetMethod(String)
07/30 01:18:14 DEBUG HttpMethodBase [5948 http://humboldt.craigslist.org:80/sfo/eby/mis/ 
3] - 
HttpMethodBase.addRequestHeader(Header)
07/30 01:18:14 DEBUG HttpClient [5948 http://humboldt.craigslist.org:80/sfo/eby/mis/  3] -
enter 
HttpClient.executeMethod(HttpMethod)
07/30 01:18:14 DEBUG HttpClient [5948 http://humboldt.craigslist.org:80/sfo/eby/mis/  3] -
enter 
HttpClient.executeMethod(HostConfiguration,HttpMethod,HttpState)
07/30 01:18:14 DEBUG MultiThreadedHttpConnectionManager [5948 http://humboldt.craigslist.org:
80/sfo/eby/mis/  3] - enter HttpConnectionManager.getConnectionWithTimeout(HostConfiguration,

long)
07/30 01:18:14 DEBUG MultiThreadedHttpConnectionManager [5948 http://humboldt.craigslist.org:
80/sfo/eby/mis/  3] - HttpConnectionManager.getConnection:  config = HostConfiguration
[host=http://humboldt.craigslist.org], timeout = 0
07/30 01:18:14 DEBUG MultiThreadedHttpConnectionManager [5948 http://humboldt.craigslist.org:
80/sfo/eby/mis/  3] - enter HttpConnectionManager.ConnectionPool.getHostPool(HostConfiguration)
07/30 01:18:14 DEBUG MultiThreadedHttpConnectionManager [5948 http://humboldt.craigslist.org:
80/sfo/eby/mis/  3] - Unable to get a connection, waiting..., hostConfig=HostConfiguration
[host=http://humboldt.craigslist.org]
=========================
(that's where it hung)

I think the key is that the connection manager is only handing one thread. your assumption
is that 
eventually there'll be another open connection that closes and notifies() the connection manager
so that 
it stops waiting. but what if there aren't any other running threads? there's nothing waiting
for an ACK 
since our only connecting thread is stopped in Thread.wait(0)... so what's going to pop us
out of the 
wait?

Now,  my understanding is fuzzy, especially the effect of the loss of internet connectivity
on the 
connection manager that's running as HTTP 1.1 and not closing connections, but i think there's
a 
genuine deadlock situation with this edge condition of a MultiThreaded...ConnectionManager
that's 
only running one thread.

Maybe your answer will be simply "don't use MultiThreaded...ConnectionManager if you only
want to 
run one thread" ;)

I'm tempted to REOPEN this but i think i'll leave that as your call... i feel like a salmon
in a barrel.

cheers,
garry

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message