org.apache.commons.net.ftp.FTPConnectionClosedException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • org.apache.commons.vfs.FileSystemException: Could not determine the type of file "ftp://". at org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1214) at org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject.java:400) at com.adeptia.indigo.event.filetrigger.FileMatcher.findFiles(FileMatcher.java:188) at com.adeptia.indigo.event.filetrigger.FileMatcher.getFileList(FileMatcher.java:117) at com.adeptia.indigo.event.ftptrigger.FtpListener.execute(FtpListener.java:122) at com.adeptia.indigo.event.AbstractListener.execute(AbstractListener.java:52) at org.quartz.core.JobRunShell.run(JobRunShell.java:203) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520) Caused by: org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed without indication. at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:267) at org.apache.commons.net.ftp.FTP.getReply(FTP.java:605) at org.apache.commons.net.ftp.FTPClient.completePendingCommand(FTPClient.java:1253) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2400) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2090) at org.apache.commons.vfs.provider.ftp.FTPClientWrapper.listFiles(FTPClientWrapper.java:105) at org.apache.commons.vfs.provider.ftp.FtpFileObject.doGetChildren(FtpFileObject.java:122) at org.apache.commons.vfs.provider.ftp.FtpFileObject.getChildFile(FtpFileObject.java:91)2008-01-04 16:33:58,375 ERROR [TestScheduler_Worker-4] Event com.adeptia.indigo.event.filetrigger.FileMatcher.getFileList(FileMatcher.java:121) - ||||administrators|||||admin|Error::org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed without indication.|localhost at org.apache.commons.vfs.provider.ftp.FtpFileObject.getInfo(FtpFileObject.java:167) at org.apache.commons.vfs.provider.ftp.FtpFileObject.doAttach(FtpFileObject.java:156) at org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1200) ... 7 more 2008-01-04 16:33:58,390 INFO [TestScheduler_Worker-4] org.quartz.core.JobRunShell org.quartz.core.JobRunShell.run(JobRunShell.java:208) - Job DEFAULT.192168001166119813685098400001:FTp_Event_outbox_prob threw a JobExecutionException: org.quartz.JobExecutionException: com.adeptia.indigo.utils.IndigoException: Could not determine the type of f [See nested exception: com.adeptia.indigo.utils.IndigoException: Could not determine the type of file at com.adeptia.indigo.event.ftptrigger.FtpListener.execute(FtpListener.java:178) at com.adeptia.indigo.event.AbstractListener.execute(AbstractListener.java:52) at org.quartz.core.JobRunShell.run(JobRunShell.java:203) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520) * Nested Exception (Underlying Cause) --------------- com.adeptia.indigo.utils.IndigoException: Could not determine the type of file at com.adeptia.indigo.event.filetrigger.FileMatcher.getFileList(FileMatcher.java:122) at com.adeptia.indigo.event.ftptrigger.FtpListener.execute(FtpListener.java:122) at com.adeptia.indigo.event.AbstractListener.execute(AbstractListener.java:52) at org.quartz.core.JobRunShell.run(JobRunShell.java:203) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520) 2008-01-04 16:35:52,312 INFO [TestScheduler_Worker-0] Event com.adeptia.indigo.event.ftptrigger.FtpListener.execute(FtpListener.java:82) - ||||administrators|||||admin|FTP Event[192168001166119813685098400001:FTp_Event_outbox_prob] triggered to check File|localhost Please response asap
    via by vikas,
  • If the connection timeout defined for the FTP server is less than the poll period defined for the channel-adapter's poller, the pool will eventually contain connections that have been dropped by the server. This results in: {code} WARNING: Failure notification received by [FtpSource] for message: null org.springframework.integration.message.MessagingException: Error while polling for messages. at org.springframework.integration.adapter.file.AbstractDirectorySource.receive(AbstractDirectorySource.java:76) at org.springframework.integration.message.MessageExchangeTemplate.doReceive(MessageExchangeTemplate.java:212) at org.springframework.integration.message.MessageExchangeTemplate.doReceiveAndForward(MessageExchangeTemplate.java:231) at org.springframework.integration.message.MessageExchangeTemplate.receiveAndForward(MessageExchangeTemplate.java:191) at org.springframework.integration.dispatcher.PollingDispatcher.run(PollingDispatcher.java:127) at org.springframework.integration.scheduling.spi.ProviderTaskScheduler$TaskRunner.run(ProviderTaskScheduler.java:221) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source) at java.util.concurrent.FutureTask.runAndReset(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.commons.net.ftp.FTPConnectionClosedException: FTP response 421 received. Server closed connection. at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:321) at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:460) at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:520) at org.apache.commons.net.ftp.FTP.port(FTP.java:849) at org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:477) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2390) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2188) at org.springframework.integration.adapter.ftp.FtpSource.populateSnapshot(FtpSource.java:90) at org.springframework.integration.adapter.ftp.FtpSource.refreshSnapshotAndMarkProcessing(FtpSource.java:79) at org.springframework.integration.adapter.file.AbstractDirectorySource.receive(AbstractDirectorySource.java:68) ... 14 more {code} It's possible to send a NOOP (No Operation) command to the FTP Server before passing the FTPClient instance on. This should restart the "connection" timer. Here's a better version of QueuedFTPClientPool.getClient(): {code} public synchronized FTPClient getClient() throws SocketException, IOException { FTPClient client = null; boolean disconnected = true; while(disconnected) { client = pool.isEmpty() ? factory.getClient() : pool.poll(); try { if(client.sendNoOp()) disconnected = false; else disconnect(client); } catch (FTPConnectionClosedException e) { disconnect(client); } } return client; } private void disconnect(FTPClient client) { try { client.disconnect(); } catch(IOException e) { //Ignore or log } } {code} This is not perfect however, since FTP servers (at least FileZilla) also define a "no transfer timeout" (the time a user has to initiate a file transfer) in addition to the "connection timeout". There seems to be no way of restarting that timer, and if the poll period and the "no transfer timeout" are close enough to each other, we could see a race condition in which the client.sendNoOp() returns true and restarts the "connection" timer, but the "no transfer timeout" expires before the client gets to transfer a file and thus holds a "dead" connection. This should be documented so the user knows to either disable the "no transfer timeout" or to use a a pool size of zero to avoid potential problems.
    via by Martti von Hertzen,
  • If the connection timeout defined for the FTP server is less than the poll period defined for the channel-adapter's poller, the pool will eventually contain connections that have been dropped by the server. This results in: {code} WARNING: Failure notification received by [FtpSource] for message: null org.springframework.integration.message.MessagingException: Error while polling for messages. at org.springframework.integration.adapter.file.AbstractDirectorySource.receive(AbstractDirectorySource.java:76) at org.springframework.integration.message.MessageExchangeTemplate.doReceive(MessageExchangeTemplate.java:212) at org.springframework.integration.message.MessageExchangeTemplate.doReceiveAndForward(MessageExchangeTemplate.java:231) at org.springframework.integration.message.MessageExchangeTemplate.receiveAndForward(MessageExchangeTemplate.java:191) at org.springframework.integration.dispatcher.PollingDispatcher.run(PollingDispatcher.java:127) at org.springframework.integration.scheduling.spi.ProviderTaskScheduler$TaskRunner.run(ProviderTaskScheduler.java:221) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(Unknown Source) at java.util.concurrent.FutureTask.runAndReset(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: org.apache.commons.net.ftp.FTPConnectionClosedException: FTP response 421 received. Server closed connection. at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:321) at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:460) at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:520) at org.apache.commons.net.ftp.FTP.port(FTP.java:849) at org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:477) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2390) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2188) at org.springframework.integration.adapter.ftp.FtpSource.populateSnapshot(FtpSource.java:90) at org.springframework.integration.adapter.ftp.FtpSource.refreshSnapshotAndMarkProcessing(FtpSource.java:79) at org.springframework.integration.adapter.file.AbstractDirectorySource.receive(AbstractDirectorySource.java:68) ... 14 more {code} It's possible to send a NOOP (No Operation) command to the FTP Server before passing the FTPClient instance on. This should restart the "connection" timer. Here's a better version of QueuedFTPClientPool.getClient(): {code} public synchronized FTPClient getClient() throws SocketException, IOException { FTPClient client = null; boolean disconnected = true; while(disconnected) { client = pool.isEmpty() ? factory.getClient() : pool.poll(); try { if(client.sendNoOp()) disconnected = false; else disconnect(client); } catch (FTPConnectionClosedException e) { disconnect(client); } } return client; } private void disconnect(FTPClient client) { try { client.disconnect(); } catch(IOException e) { //Ignore or log } } {code} This is not perfect however, since FTP servers (at least FileZilla) also define a "no transfer timeout" (the time a user has to initiate a file transfer) in addition to the "connection timeout". There seems to be no way of restarting that timer, and if the poll period and the "no transfer timeout" are close enough to each other, we could see a race condition in which the client.sendNoOp() returns true and restarts the "connection" timer, but the "no transfer timeout" expires before the client gets to transfer a file and thus holds a "dead" connection. This should be documented so the user knows to either disable the "no transfer timeout" or to use a a pool size of zero to avoid potential problems.
    via by Martti von Hertzen,
    • org.apache.commons.net.ftp.FTPConnectionClosedException: FTP response 421 received.  Server closed connection. at org.apache.commons.net.ftp.FTP.__getReply( ) at org.apache.commons.net.ftp.FTP.sendCommand( ) at org.apache.commons.net.ftp.FTP.sendCommand( ) at org.apache.commons.net.ftp.FTP.port( ) at org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:463) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2296) at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2269) at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2047)
    No Bugmate found.