Seems like that made it. I used a new FTPClient for each file to download, that worked now in the JUnit. Will try it this weekend to get the same in my application. Thanks!

Am 30.08.2016 um 16:23 schrieb sebb:
On 29 August 2016 at 18:28, Oliver Zemann <oliver.zem...@gmail.com> wrote:
My download method looks like this:

private void downloadDirectory(FTPClient client, String sourceDir, String
destDir,
                                    ScheduledExecutorService
scheduledExecutorService) throws IOException {

         final FTPFile[] ftpFiles = client.listFiles(sourceDir);
         for (final FTPFile ftpFile : ftpFiles) {

             //skip . and ..
             if (ftpFile.isDirectory() && (ftpFile.getName().equals(".") ||
ftpFile.getName().equals(".."))) {
                 continue;
             }

             if (ftpFile.isDirectory()) {
                 downloadDirectory(client, sourceDir + ftpFile.getName(),
destDir + "/" + ftpFile.getName(), scheduledExecutorService);
             } else {
//                scheduledExecutorService.submit(new
DownloadRunnable(destDir, ftpFile, sourceDir, client));
                 FileOutputStream fos = new
FileOutputStream(ftpFile.getName());
                 client.retrieveFile(sourceDir + ftpFile.getName(), fos );
                 fos.flush();
                 fos.close();
             }
         }
     }

When i run it like this, it works and it downloads the files. But when i use
the scheduledExecuterService, it fails.
So i replaced the 2 lines with my download method (where it uses the
inputstream) to see what happens:

  } else {
//                scheduledExecutorService.submit(new
DownloadRunnable(destDir, ftpFile, sourceDir, client));
                 new File(destDir).mkdirs();
                 final File outFile = new File(destDir, ftpFile.getName());
                 final FileOutputStream fos = new FileOutputStream(outFile);
                 final InputStream inputStream =
client.retrieveFileStream(sourceDir + ftpFile.getName());

                 byte[] buffer = new byte[8096];
                 int len = -1;
                 try {
                     len = inputStream.read(buffer, 0, buffer.length);
                 } catch (Exception ex) {
                     ex.printStackTrace();
                 }
                 while (len != -1) {
                     fos.write(buffer, 0, len);
                     len = inputStream.read(buffer);
                     if (Thread.interrupted()) {
                         throw new InterruptedException();
                     }
                 }
                 client.completePendingCommand();
//                informListenersWeFinishedOneFile(sourceDir +
ftpFile.getName(), bytesWritten);
                 fos.flush();
                 fos.close();
             }
         }

That works too?!

I will go deeper into that at weekend and check whats going on, but at the
moment i really dont understand it. Maybe some kind of concurrency problem
with FTPClient?
That seems the most likely.

FTPClient is not guaranteed to be thread-safe.
I'm not sure that the java.io classes such as InputStream are thread
safe either.

Am 29.08.2016 um 01:40 schrieb Martin Gainty:
possible timeout waiting for FTP to reply
examples.ftp.FTPClientExample says to increase FTP reply timeout with -w
parameter
   if (args[base].equals("-w")) {
controlKeepAliveReplyTimeout = Integer.parseInt(args[++base]);            }
or with FTPClient:ftpClient.setControlKeepAliveReplyTimeout(2000); //2 sec
reply timeout
?
Martin
______________________________________________



Date: Sun, 28 Aug 2016 20:06:46 +0200
From: e...@zusammenkunft.net
To: user@commons.apache.org
CC: oliver.zem...@gmail.com
Subject: Re: NPE in getRemoteAdress

Hello,

I am not sure about your NPE, but this code here ignores the result of
the read call. It cannot deal with short reads:

   Am Sun, 28 Aug 2016
15:50:36 +0200 schrieb Oliver Zemann <oliver.zem...@gmail.com>:
byte b[] =new byte[4096];
while (inputStream.read(b) != -1) {
    fos.write(b);
    bytesWritten += b.length;

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Reply via email to