Major Description
Currently we're using common-pool to store those ftpClient, and sometimes the storeFile() method return false with reply "200 send noop successfully".
primary: host: nycsdevfeed.rrdev.dev.reuters.com port: 21 userName: anonymous password: anonymous role: 0 baseDir: / tempFolder: temp/ controlEncoding: UTF-8 useEPSVWithIPv4: false passiveMode: true dataTimeout: 20000 #ms, transfer command timeout in passive mode connectTimeout: 10000 #ms, socket connection timeout fileType: 2 bufferSize: 524288 #512 * 1024 controlKeepAliveTimeout: 110 #seconds, keep control command alive, send a NOOP approximately every 5 mins controlKeepAliveReplyTimeout: 45000 maxTotal: 5 #max total object in pool, default 8 maxIdle: 5 #max idle object in pool, default 8 minIdle: 2 #min idle object in pool, default 0 testOnCreate: true #verify the validateObject when create object to pool testOnReturn: true #verify the validateObject when return object to pool testOnBorrow: true #verify the validateObject when borrow object to pool testWhileIdle: true #verify the validateObject when evict thread return false(no need to remove idle object) timeBetweenEvictionRunsMillis: 60000 #check the idle object every 60 seconds softMinEvictableIdleTimeMillis: 120000 #keep the minIdle count idle object, remove the redundant idle object numTestsPerEvictionRun: 5 #evict thread will pick up 10 object to verify blockWhenExhausted: true #if there is no more idle object, block the thread until maxWaitMillis maxWaitMillis: -1 #if there is no more idle object, it will throw NoSuchElementException; -1 means always wait
This is the connection poo setting for FtpClient.
and we found that code in FTPClient.openDataConnection()
even the pasv() method return 227, but here still return null, then storeFile() return false with 200 noop reply.
