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=39377>. 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=39377 Summary: [net] TelnetInputStream.read hangs when socket data ends in a command sequence Product: Commons Version: unspecified Platform: All OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Net AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] Background: If one calls TelnetInputStream.read() in single-threaded mode (no reader thread) and there is no data immediately available, the call blocks on a socket read. When data starts to arrive, the stream adds all the available bytes to its internal queue before returning the first one to the caller. To do this, it calls __read() in a loop for as long as there are bytes available. The __read() method returns the first byte of "user data" from the socket. If __read() encounters a Telnet command sequence (IAC, WILL, WONT, DO, DONT, etc.), it handles the negotiation transparently and then returns the first byte of user data. In most cases, this works fine, but a problem arises if a chunk of data from the remote host ends in a Telnet command sequence. When that happens, the TelnetInputStream.read() method hangs, even though it may have already acquired some user data. This is because it calls __read() in a loop as long as super.available() returns true. But if the remaining data from the socket consists entirely of Telnet commands, __read() will process those AND THEN BLOCK waiting for user data. Just checking super.available() is not sufficient. We should continue the loop only if there are bytes of USER DATA still available from the socket. Not doing this can cause the client to wait indefinitely. -- 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]
