DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-11-15 13:37 --- I cannot reproduce this. If there actually was a bug, the change introduced in Tomcat 4.1.14 will fix it. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 --- Additional Comments From [EMAIL PROTECTED] 2002-11-05 09:09 --- I don't know if: - this is actually causing the bug, and if just disconnecting fixes it (the feedback given is cryptic) - having a 0 result is a normal result (if it's not we should disconnect, otherwise, we add a sleep and a max retry) -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 --- Additional Comments From [EMAIL PROTECTED] 2002-11-05 11:45 --- That's incorrect, as len is never 0. The javadocs explicitely said that the call will block until at least one byte is read. Also, I'm not convinced there's a problem, as the only major problem reported with Coyote HTTP/1.1 has been the sever socket dying (apparently because of bugs in the VM network code; workarounds similar to those in 4.0.x were added in 4.1.14 to fix that). -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 [EMAIL PROTECTED] changed: What|Removed |Added Component|Connector:Coyote HTTP/1.1 |Unknown -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 [EMAIL PROTECTED] changed: What|Removed |Added Component|Unknown |Connector:Coyote HTTP/1.1 -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 --- Additional Comments From [EMAIL PROTECTED] 2002-10-31 23:23 --- OK I suppose that the I/O call should not return 0, but, If it returns 0, the system hangs up. Maybe is a JDK bug or a Linux bug, but I think we must prevent the Tomcat hangup exiting the while ig the call returns 0. Remmy, Don't you think so? So, Should I or you reopen the bug? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 --- Additional Comments From [EMAIL PROTECTED] 2002-11-01 02:57 --- The 0 case did worry me. It should mean that no imput is available (e.g. a slow network connection), but I don't know why it should stay in that state. It would be nice to be able to find out the underlying cause. It should be possible to add a counter to limit the max-tries on recieving a 0 response, and, possibly add a Thread.sleep(1). This would at least allow the other Tomcat threads to be usable while this one is waiting. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
DO NOT REPLY [Bug 13759] - Tomcat Coyote hangs at fill() spending 100% CPU
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=13759. 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 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-10-18 12:53 --- This line is a blocking I/O call, so I don't see how it would hang there, unless the call returns 0 (but I don't think it's supposed to), in which case a loop condition might occur. You'll have to debug this further, as the report doesn't allow to reproduce it nor isolate any particular problem. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
