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 ------- Additional Comments From [EMAIL PROTECTED] 2006-04-24 19:41 ------- Created an attachment (id=18174) --> (http://issues.apache.org/bugzilla/attachment.cgi?id=18174&action=view) Fix read hang after command sequence This patch prevents the read hang that occurs in single-threaded mode when a remote host response ends in a Telnet command sequence. I have added a boolean flag to TelnetInputStream.__read that tells it whether or not to block on a socket read if there is no user data available in the superclass buffer. It is set to true for the first iteration through the loop in read(), which is the only time we need to wait. Subsequent iterations only serve to eagerly fill the queue, so we don't need to wait, and the argument is set to false. If the argument is false and there is no data available, __read() returns a value of -2 that prevents the caller from using the data. I didn't use an exception because of overhead concern. (We could hit this condition often.) If the reader thread is enabled, run() calls __read() with the argument set to true, which is equivalent to the old behavior. -- 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]
