Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 69417 invoked from network); 5 Nov 2002 11:32:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Nov 2002 11:32:35 -0000 Received: (qmail 1413 invoked by uid 97); 5 Nov 2002 11:33:24 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 1397 invoked by uid 97); 5 Nov 2002 11:33:24 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 1383 invoked by uid 50); 5 Nov 2002 11:33:23 -0000 Date: 5 Nov 2002 11:33:23 -0000 Message-ID: <20021105113323.1382.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . 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=13759 Tomcat Coyote hangs at fill() spending 100% CPU vicentesalvador@netscape.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | ------- Additional Comments From vicentesalvador@netscape.net 2002-11-05 11:33 ------- On JDK Api Docs, about InputStream.read(): If len is zero, then no bytes are read and 0 is returned; otherwise, there is an attempt to read at least one byte. If no byte is available because the stream is at end of file, the value -1 is returned; otherwise, at least one byte is read and stored into b. So a 0 and a -1 can be returned by read() and it means that there is not more data available, so I think we just should disconnect. Surelly this is causing the bug, because if 0 or -1 is returned, then lastValid variable is not updated and doRead stands calling fill() forever. Now I will reopen the bug... If you don't agree, feel free to resolve it again!!! -- To unsubscribe, e-mail: For additional commands, e-mail: