DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38688>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38688 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|[net] TelnetInputStream.read|[net][PATCH] |sometimes hangs if reader |TelnetInputStream.read |thread is disabled |sometimes hangs if reader | |thread is disabled ------- Additional Comments From [EMAIL PROTECTED] 2006-03-15 22:44 ------- I believe what's happening is the buffer (queue) fills up and there is still more data to be read from the socket. When this happens in threaded mode, the reader thread waits in __processChar, giving the consumer thread a chance to drain the buffer. That seems to work fine. When threaded mode is disabled, however, we need to stop collecting data from the socket and return some of what we have so far to the caller. In other words, we shouldn't read any more from the socket or call __processChar unless there is still room left in the queue to hold new data. I've submitted a patch that I think fixes the problem. But since I'm unfamiliar with this code (and this is my first Commons contribution), please take a close look! Basically, what I've done is add a check in read() to the while loop that was adding data to the queue for non-threaded mode. If the queue is full, the loop will terminate now. I also added a safety check to the code in __processChar that will throw an IllegalStateException if it is called in non-threaded mode and the queue is full. That should never happen. All unit tests pass, and the new code prevented hangs in my ad hoc tests. I tested it by submitting a command via Telnet to a host that causes it to respond with a lot of data (e.g. "cat somebigtextfile.txt"). Then I put the client thread to sleep for a few seconds before trying to read any of the response. This consistently caused a hang with the old code, but not with the patch. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
