DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16458>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16458 HttpClient enter 100% for endless time ------- Additional Comments From [EMAIL PROTECTED] 2003-02-20 17:00 ------- The bug appears to have been found by Sam Maloney <[EMAIL PROTECTED]> =========================================================================== Here is the problem: at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:46) at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:81) at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:878) at org.apache.commons.httpclient.HttpConnectionAdapter.readLine(MultiThreadedHttpConnectionManager_fixed.java:730) at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1917) You can see that readStatusLine looks like this: <SNIP> //read out the HTTP status string String statusString = conn.readLine(); while ((statusString != null) && !statusString.startsWith("HTTP/")) { statusString = conn.readLine(); } if (statusString == null) { // A null statusString means the connection was lost before we got a // response. Try again. throw new HttpRecoverableException("Error in parsing the status " + " line from the response: unable to find line starting with" + " \"HTTP/\""); } </SNIP> You can see from the above code, that until conn.readLine() returns null or a string starting with "HTTP/", this piece of code will keep looping indefinatly (what is taking 100% CPU). Right now, readLine never will return null, only empty strings. I'm guessing readLine must have returned null at one point, as every place that calls it expects null to be returned on closed connection. The way readLine must work for the calling code to work is: 1) Read data upto \r\n, return line. (currently happens) 2) if EOF before finding \r\n, but we have data in our buffer, return the buffer. (also happens) 3) if EOF before finding any data (buf.size()==0), then return null to signal that no more data is possible, and caller should NOT call again. (this is what patch adds) If we return empty string like is happening currently, then the caller will not know NOT to call again. In this bugs case, the caller keeps reading lines until it finds 'HTTP/'. Since the empty string doesn't match that, the caller will keep trying to get the next line, and they will just keep getting "". Here is my patch again, updated to apply to HttpParser (where the readLine code has been moved to since my last patch). I have retested the new patch and it is working in all my test cases, including the one to reproduce the bug. Index: HttpParser.java =================================================================== RCS file: /home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/HttpParser.java,v retrieving revision 1.1 diff -u -r1.1 HttpParser.java --- HttpParser.java 16 Feb 2003 13:10:16 -0000 1.1 +++ HttpParser.java 20 Feb 2003 15:51:51 -0000 @@ -58,6 +58,10 @@ } } } + if (buf.size() <= 0) { + // Then we just started reading, but the stream is EOF (closed). + return null; // Let caller know we got EOF BEFORE any data. + } if (WIRE_LOG.isDebugEnabled()) { WIRE_LOG.debug("<< \"" + buf.toString() + (ch>0 ? "\" [\\r\\n]" : "")); } @@ -79,6 +83,12 @@ public static String readLine(InputStream inputStream) throws IOException { LOG.trace("enter HttpConnection.readLine()"); byte[] rawdata = readRawLine(inputStream); + + if (rawdata == null) { + // Then there was EOF before any data was read, we must let caller know. + return null; + } + int len = rawdata.length; if (( len >= 2) && (rawdata[len - 2] == '\r') && (rawdata[len - 1] == '\n')) { return HttpConstants.getString(rawdata, 0, rawdata.length - 2); --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
