Issue Details (XML | Word | Printable)

Key: NET-146
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Koloom
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Commons Net

wrong handling of timeouts

Created: 18/Dec/06 08:57 PM   Updated: 20/Dec/06 10:54 AM
Return to search
Component/s: None
Affects Version/s: 1.4
Fix Version/s: 2.0

Time Tracking:
Not Specified

Environment: linux 2.6, java 1.5.0_08 (but most probably any environment)

Resolution Date: 20/Dec/06 10:54 AM


 Description  « Hide
If you set a timeout on the control connection and then make a data transfer (upload, download) which takes longer than that timeout, the client throws the following exception. It seems like the client tries to read something from the control connection while the data transfer is in progress and then it just throws an exception. It makes the application think that the transfer failed even though it succeeded.

aused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at java.io.FilterInputStream.read(FilterInputStream.java:66)
at java.io.PushbackInputStream.read(PushbackInputStream.java:120)
at org.apache.commons.net.io.FromNetASCIIInputStream.__read(FromNetASCIIInputStream.java:75)
at org.apache.commons.net.io.FromNetASCIIInputStream.read(FromNetASCIIInputStream.java:170)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:235)
at org.apache.commons.net.telnet.TelnetInputStream.__read(TelnetInputStream.java:114)
at org.apache.commons.net.telnet.TelnetInputStream.run(TelnetInputStream.java:535)
at java.lang.Thread.run(Thread.java:595)



 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Koloom added a comment - 18/Dec/06 09:02 PM
Following is an InputStream implementation which slows down the data transfer (upload). Just to make your testing easier . I could not attach the complete test since I use another layer on top of commons-net and I am not free to distribute it.

public class DelayedByteArrayInputStream extends InputStream {
private byte[] data;
private int position;
private long chunkDelay;
private final static int CHUNK = 10000;

public DelayedByteArrayInputStream(byte[] data, long time) { this.data = data; position = 0; double x = time / (data.length / CHUNK); chunkDelay = Math.round(Math.ceil(x)); }

public int read() throws IOException {
if (position % CHUNK == 0) {
try { Thread.sleep(chunkDelay); }
catch (InterruptedException e) { throw new IOException("sleep interrupted"); }
}
return position < data.length ? data[position++] : -1;
}
}


Rory Winston added a comment - 18/Dec/06 09:47 PM
Hi
Can you post the code where you are setting the timeout? I cant reproduce the problem...

Have you tried the latest RC of net-2.0 ? You can find it here:

http://people.apache.org/~rwinston/commons-net-2.0/commons-net-ftp-2.0.0-SNAPSHOT.jar


Daniel Savarese added a comment - 19/Dec/06 08:18 PM
The documentation for FTPClient in Commons Net 1.4.1 says:
>NOTE: If you experience problems with unwanted firing of.
>setSoTimeout() during periods of client inactivity, this can be alleviated by calling
>setReaderThread(false). For more details, see this thread (http://issues.apache.org/bugzilla/show_bug.cgi?id=31122).

Daniel Savarese added a comment - 19/Dec/06 09:29 PM
After reviewing the old bugzilla issue, I think the problem is that the telnet protocol implementation for the control connection always sits in a read waiting for events (and that read is timing out). If that read were started only after the data transfer completed, it wouldn't time out. If that's the case, then, yes, that would be a bug and that's why disabling the reader thread works around the problem. Rory's changes for 2.0 won't have the problem because it doesn't use TelnetClient.

Rory Winston added a comment - 20/Dec/06 10:54 AM
Fixed in 2.0 branch.