Yup, I'm trying it on OS X and linux. I think the problem is in HttpMethodBase.execute() in particular the following line:
if (responseStream != null) { responseStream.close(); }
Since there is no content length or chunking the response stream is not being wrapped and is therefore actually closed by the above code. Take a look at AutoCloseInputStream.close(). I vaguely remember talking about this case when we added the connection release/reuse code. I may be wrong but I think that the connection should be getting closed in this case as there is no safe way to consume the response.
Ahhh, that'd be it, yep. I'll take a look at better ways to detect that after lunch (collegues are dragging me to the pub now). Below is a correction to my last patch to detect and recover from the problem, but I'd prefer to avoid it altogether. The most obvious solution seems to be to wrap the responseStream so that when close is called it tells HttpConnection that it's been closed.
Mike
Index: HttpConnection.java
===================================================================
RCS file: /home/cvs/jakarta-commons/httpclient/src/java/org/apache/commons/ httpclient/HttpConnection.java,v
retrieving revision 1.67
diff -u -r1.67 HttpConnection.java
--- HttpConnection.java 26 May 2003 22:07:21 -0000 1.67
+++ HttpConnection.java 20 Jun 2003 02:13:42 -0000
@@ -480,6 +480,16 @@
LOG.debug("Connection is stale, closing...");
close();
}
+ if (inputStream != null) {
+ try {
+ if (inputStream.available() < 0) {
+ close();
+ }
+ } catch(IOException e) {
+ close();
+ LOG.debug("Underlying connectin is closed.", e);
+ }
+ }
return isOpen;
}
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
