数据交换中的FTP操作包选型

整理一下前段时间做的基于FTP操作的数据交换服务的经历，希望对大家有所帮助

1. 首先是FTP选型

   首先有两个选项大名鼎鼎的 APACHE COMMON NET 和EDT FTP

   因为EDT FTP是收费的，所以否决了，看来要看APACHE 基金下大名鼎鼎的APACHE COMMON NET的表现了

2. 用COMMON NET 1不亦乐乎的开发一段时间。

3. 把COMMON NET 1升级成了COMMON NET 2, 并改了一个BUG（MDTM）

4. FTP连接是一种资源，但是所有的FTP API包都没有提供一种好的持续操作的方式。

   联想到数据库的连接池，采用了该方法改造了对FTP的操作，而且采用的是APACHE COMMON POOL, 果然效果好了很多

   对APACHE印象再加分。

5. 多线程的FTP操作-这个大概是这个项目中最深刻的教训

   问题起源于数据交换可能有多个FTP客户端。在一个任务调度的工厂里面有多个FTP操作线程在跑的时候，不可预料的事情发生了。

   ....

   追踪了N久，终于有一天打开COMMON NET的源码，发现一个令人惊叹的问题：COMMON NET 2的FTP操作是没有同步的！

   众所周知FTP操作象唱山歌一样，你应我答，这样才能谈情说爱，但是因为应答没有同步，你应的可能不是你的意中人，太可怕了。

   我做出了一个英明神武的决定，放弃了APACHE COMMON NET。APACHE减分！

6. 意大利人的FTP4J

    放弃COMMON NET的同时 我看好了另外一个意大利人写FTP包-FTP4J， 同样是开源的，而且看源码是同步的，看来多线程的山歌有希望了。

    对FTP4J重新封装了连接池模式，测试，证明除了一开始报了一个异常，后面都很正常。

   再测试FTP4J也有些小问题，不过稍稍改了一下源码就解决了。

   又持续测试了很久，事实证明FTP4J比APACHE COMMON 的FTP优秀很多，可能因为他很专注在FTP,不象COMMON NET支持了很多的协议，结果却没有考虑同步的问题 。如果要用他的话只能在单线程模式下跑了。

教训：采用怀疑一切的态度选型。

注 在此艰难过程中得到了车凡的全力支持，给我提供了大量的测试样例和反馈，我要感谢他