You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2006/04/21 16:15:58 UTC
DO NOT REPLY [Bug 39377] New: - [net] TelnetInputStream.read hangs when socket data ends in a command sequence
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: commons-dev@jakarta.apache.org
ReportedBy: rhasselbaum@alumni.ithaca.edu
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 39377] - [net] TelnetInputStream.read hangs when socket data ends in a command sequence
Posted by bu...@apache.org.
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 rhasselbaum@alumni.ithaca.edu 2006-04-21 17:40 -------
I am working on a patch now. If someone can commit my earlier patch for bug
38688, we can avoid a messy merge later, as this impacts some of the same code.
--
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 39377] - [net][PATCH] TelnetInputStream.read hangs when socket data ends in a command sequence
Posted by bu...@apache.org.
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
rwinston@eircom.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
------- Additional Comments From rwinston@eircom.net 2006-08-30 14:46 -------
This has been applied
--
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 39377] - [net][PATCH] TelnetInputStream.read hangs when socket data ends in a command sequence
Posted by bu...@apache.org.
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
rhasselbaum@alumni.ithaca.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[net] TelnetInputStream.read|[net][PATCH]
|hangs when socket data ends |TelnetInputStream.read hangs
|in a command sequence |when socket data ends in a
| |command sequence
--
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 39377] - [net] TelnetInputStream.read hangs when socket data ends in a command sequence
Posted by bu...@apache.org.
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 dfs@apache.org 2006-04-23 17:02 -------
Patch for bug 38688 applied. Thanks!
--
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 39377] - [net] TelnetInputStream.read hangs when socket data ends in a command sequence
Posted by bu...@apache.org.
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
rhasselbaum@alumni.ithaca.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |major
--
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 39377] - [net] TelnetInputStream.read hangs when socket data ends in a command sequence
Posted by bu...@apache.org.
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
dfs@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
------- Additional Comments From dfs@apache.org 2006-04-21 17:37 -------
Can you submit a patch that corrects the error? All I can offer you in return
is our thanks and the addition of your name to the list of contributors.
--
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 39377] - [net] TelnetInputStream.read hangs when socket data ends in a command sequence
Posted by bu...@apache.org.
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 rhasselbaum@alumni.ithaca.edu 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org