nlight-jdev / jcouchdb

Automatically exported from code.google.com/p/jcouchdb
Other
0 stars 0 forks source link

Http Connections are not properly closed which causes the HttpClient to block infinitely #24

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Set maxConnectionsPerRoute and maxTotalConnections of the ServerImpl to 1. 
(Actually the number doesn't matter. Setting it to 1 will just make the problem 
occur earlier.)
2. Make multiple consecutive calls to the same host.
3. In my case the HttpClient ended up infinitely waiting for new connections.

What is the expected output? What do you see instead?
For testing I limited the number of connections to 1 and still expected all my 
tests to run smoothly. Unfortunately only the first request was successful and 
after that I always saw the following 
log output:

18:06:51:829 - DEBUG - ServerImpl - PUT /database_name/, body = null
18:06:51:830 - DEBUG - ThreadSafeClientConnManager$1 - 
ThreadSafeClientConnManager.getConnection: 
HttpRoute[{}->http://192.168.1.168:5984], timeout = 0
18:06:51:831 - DEBUG - ConnPoolByRoute - Total connections kept alive: 0
18:06:51:842 - DEBUG - ConnPoolByRoute - Total issued connections: 1
18:06:51:843 - DEBUG - ConnPoolByRoute - Total allocated connection: 1 out of 1
18:06:51:844 - DEBUG - ConnPoolByRoute - No free connections 
[HttpRoute[{}->http://192.168.1.168:5984]][null]
18:06:51:846 - DEBUG - ConnPoolByRoute - Available capacity: 1 out of 1 
[HttpRoute[{}->http://192.168.1.168:5984]][null]
18:06:56:106 - DEBUG - ConnPoolByRoute - Need to wait for connection 
[HttpRoute[{}->http://192.168.1.168:5984]][null]

After digging deeper into jcouchdb and the httpclient library, I found the 
following example page 
(http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/
examples/org/apache/http/examples/client/ClientConnectionRelease.java), which 
mentions that 
connections are released once the close method of the Response InputStream has 
been called. I located the point where jcouchdb reads from the InputStream 
(org.jcouchdb.db.Response) and 
realized that it doesn't seem to be closed afterwards. Once I modified the 
Class to close the InputStream (after reading the data, plus - to be save - in 
the destroy method), my problem was 
gone. It seems pretty obvious to me that this was a general issue, but I find 
it hard to believe that nobody else has been complaining about this. So 
probably it was just something really weird 
that only happened to me. In any case, I attached a patch that resolved the 
issue for me. I hope it helps!

I am using jcouchdb version 0.9.1-1 and httpclient 4.0.1 by the way. (I tried 
this on various CouchDB versions from 0.8.x to 0.10.x)

Original issue reported on code.google.com by dbech...@gmail.com on 9 Sep 2009 at 12:49

Attachments:

GoogleCodeExporter commented 8 years ago
This issue was closed by revision r146.

Original comment by ff...@gmx.de on 12 Sep 2009 at 8:59