[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-user
Subject:    Re: NPE in getRemoteAdress
From:       sebb <sebbaz () gmail ! com>
Date:       2016-08-31 9:34:16
Message-ID: CAOGo0VbwSnhgqepMAG8MZd_vFzj3N0ATQMJVHT3ufyDjkc6JkA () mail ! gmail ! com
[Download RAW message or body]

FTPClient instances are independent; each can be used by a separate thread.
However note that the instances are not inherently thread-safe.

So either create the instance in the same thread that does the download.

Alternatively, create the client before creating the thread, and
ensure that the client is only used by the new thread once created.

On 30 August 2016 at 20:53, Oliver Zemann <oliver.zemann@gmail.com> wrote:
> 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.zemann@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: ecki@zusammenkunft.net
>>>>> To: user@commons.apache.org
>>>>> CC: oliver.zemann@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.zemann@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: user-help@commons.apache.org
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: user-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>

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

[prev in list] [next in list] [prev in thread] [next in thread]