d********r
发帖数: 199 | 1 我有一段很简单的code, 功能是read一个InputStream, 然后写到一个OutputStream里
去。
如果这个InputStream是从一个URL打开的，
比如：
InputStream in = new Url("http://someurl").openStream();
基本不会有问题。
但如果是来自一个ftp url, "ftp://someserver/path/filename"
则可能会有问题。
我发现，对某个server的某个大文件（28M左右），
到流已经读完的时候（因为我知道文件有多大），就是read(buffer)该返回-1的时候，
它会被block了，
就是会陷入无限等待，永远也不返回。
我发现只是对某些文件这样。对同一个remote server上同一目录下的其它小文件则没
问题。
该文件可以被Flashget正常下载。
如果我把这个文件放到我local自己建的测试ftp server上（其实也得通过internet,都
是外部地址）
，则也不会有问题。
请问这可能是什么原因，如何应对？
code 如下：
public static l |
b******y
发帖数: 9224 | 2 input stream可能需要close() statement?否则程序就无限期等？ |
h*********o
发帖数: 62 | 3 Not sure if this caused your problem. But I doubt it
It seems that there is a small bug in the code. Since the network is slower
than cpu, cpu will dump data much faster than network. This will cause
sometimes inputstream to read empty tempary stream ( the stream is not
closed yet). So the count can be 0. I suggest that you cahnge:
if (count <= 0) break;
to if (count == -1) break;
Please note that this doesn't happen so often. But you still have a chance
to truncate your file.
To debug your code |
d********r
发帖数: 199 | 4 多谢回复。
不过你说的这个bug实际上并不会发生。
因为程序无限等待发生在这个if (count <= 0) break;语句的前一句：
in.read(buffer)
这时候，我根据总字节数判断，知道肯定还有available的byte需要读。
我实际上监视过每一次读进来的byte count,尽管每次都不见得一样
（并不一定等于buffer size，而是有可能小于），但也不会<=0,
所以这段code从来不会提前break
slower
bytes
【在 h*********o 的大作中提到】
: Not sure if this caused your problem. But I doubt it
: It seems that there is a small bug in the code. Since the network is slower
: than cpu, cpu will dump data much faster than network. This will cause
: sometimes inputstream to read empty tempary stream ( the stream is not
: closed yet). So the count can be 0. I suggest that you cahnge:
: if (count <= 0) break;
: to if (count == -1) break;
: Please note that this doesn't happen so often. But you still have a chance
: to truncate your file.
: To debug your code
|
d********r
发帖数: 199 | 5 update:
我又把这段code拿到家里(comcast cable)测试了一下，发现没问题。
但是在学校里run就会有问题，
可能是学校的网络有什么特别的地方造成的。
update again:
Faint! 发现问题所在了：
竟然是Windows Firewall造成的。
关了Windows Firewall就没问题了。NND,害我搭进去一天多找原因。
【在 d********r 的大作中提到】
: 我有一段很简单的code, 功能是read一个InputStream, 然后写到一个OutputStream里
: 去。
: 如果这个InputStream是从一个URL打开的，
: 比如：
: InputStream in = new Url("http://someurl").openStream();
: 基本不会有问题。
: 但如果是来自一个ftp url, "ftp://someserver/path/filename"
: 则可能会有问题。
: 我发现，对某个server的某个大文件（28M左右），
: 到流已经读完的时候（因为我知道文件有多大），就是read(buffer)该返回-1的时候，
|
h*********o
发帖数: 62 | 6 it is great you solved the problem.
go read "java network programming", you will understand why you shouldn't
use count <= 0. |
m******t
发帖数: 2416 | 7
How are you going to make sure your users turn off their Windows Firewall
though?
【在 d********r 的大作中提到】
: update:
: 我又把这段code拿到家里(comcast cable)测试了一下，发现没问题。
: 但是在学校里run就会有问题，
: 可能是学校的网络有什么特别的地方造成的。
: update again:
: Faint! 发现问题所在了：
: 竟然是Windows Firewall造成的。
: 关了Windows Firewall就没问题了。NND,害我搭进去一天多找原因。
|
F****n
发帖数: 3271 | 8 如何解决I/O的BLOCK是JAVA里一个经典的问题
常见的做法是设一个TIMER检查TIME OUT，如果到期就关闭连接
这样InputStream.read()会throw 一个 exception
【在 m******t 的大作中提到】
:
: How are you going to make sure your users turn off their Windows Firewall
: though?
|
