|
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 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 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.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||
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;
}
}