关于completePendingCommand
文件系统无非就是文件的存取和组织结构。 访问一个文件系统的API也应该是写,读,定位方法(Pathname?/URI?)
FTPClient针对文件的保存和获取各提供了两个方法,分别是:
- publicboolean storeFile(String remote, InputStream local)
- public OutputStream storeFileStream(String remote)
- publicboolean retrieveFile(String remote, OutputStream local)
- public InputStream retrieveFileStream(String remote)
public boolean storeFile(String remote, InputStream local) public OutputStream storeFileStream(String remote) public boolean retrieveFile(String remote, OutputStream local) public InputStream retrieveFileStream(String remote)
两个方法貌似相同,实际不同,返回流的那个因为不能马上处理流,所以需要用户手工调用completePendingCommand,而另一个传递流进去的则不需要。可能有同学已经遇到过这个问题了,读写第一个文件时总是正确的,当相同API读写第二个文件时,block住了。这是因为FTPClient要求在进行流操作之后执行completePendingCommand,以确保流处理完毕,因为流处理不是即时的,所以也没有办法不手工调用completePendingCommand。问题是开发者把不返回流的方法末尾加上了completePendingCommand,如果不看代码可能根本不知道。 文档上说:
但是这样仍然还是让人有点困惑,为什么都是存储/读取的方法,有时候要调用completePendingCommand,有时候不调用?更严重的问题是completePendingCommand调用了getReply,如果一个命令通过socket stream传了过去但是没有getReply,即没有completePendingCommand,那么下次发命令时,将会受到本次返回码的干扰,得到无效的响应。而如果在completePendingCommand之后又进行了一次无辜的completePendingCommand,那么因为FTP Server上没有Reply了,就会block。所以completePendingCommand并不是可以随意添加的。
现在出现了两个问题: 1 completePendingCommand很容易多出来或遗漏 2 显式调用completePendingCommand暴露了底层实现,给用户带来不便,用户只想要InputStream或者OutputStream
为了解决这个问题,可以对InputStream进行扩展,建立一个ReplyOnCloseInputStream,如下:
- privatestatic ReplyOnCloseInputStream extends InputStream{
- //...
- public ReplyOnCloseInputStream(InputStream is, FTPClient c){
- //...
- }
- //...
- @override
- publicvoid close(){
- if(c.completePendingCommand){
- is.close();
- }else{
- //throw Exception
- }
- }
- }
- //...
- returnnew ReplyOnCloseInputStream(is, client);
private static ReplyOnCloseInputStream extends InputStream{ //... public ReplyOnCloseInputStream(InputStream is, FTPClient c){ //... } //... @override public void close(){ if(c.completePendingCommand){ is.close(); }else{ //throw Exception } } } //... return new ReplyOnCloseInputStream(is, client);
这样封装之后,FTPClient的用户只需要正常在处理完流之后关闭即可,而不必暴露实现细节。保存文件也可以用相同的方法封装OutputStream。