1

I have a java code that was written by some guy before me. The code works fine in AIX but we had to recently move all scripts from AIX to RHEL 7.6. On RHEL the code seems to get stuck in an long loop and the scipts which takes around 5 minutes to completed takes hours just going through that loop.

The loop uses SmbFileInputStream and BufferedOutputStream. The logs do not show any error/exception.

Any help would be highly appreciated as the AIX servers would be de-commissioned in the next week and I need to make it work on RHEL.

public File getSMBFile(SmbFile infile, String username, String password, String localdir) throws Exception {

    SmbFileInputStream smbIn = new SmbFileInputStream(infile);
    //File temp = File.createTempFile(infile.getName(), null);
    //temp.deleteOnExit();

    File localFile = new File(localdir, infile.getName());
    BufferedOutputStream out = new BufferedOutputStream(new FileOutputStream(localFile));

    byte[] b = new byte[8192];
    int n = 0;

    while ((n = smbIn.read(b)) > 0) {
        log.info("In while" + localFile + " to " + b + " " + 0 + " " + n);
        out.write(b, 0, n);
    }

    out.flush();
    out.close();

    smbIn.close();
    out.close();
    log.info("LocalFile " + localFile);
    return localFile;
}

This loop is where the code goes into an infinite loop and keeps running for hours:

while ((n = smbIn.read(b)) > 0) {
    log.info("In while" + localFile + " to " + b + " " + 0 + " " + n);
    out.write(b, 0, n);
}

Log output: Dec 30, 2019 10:16:18 PM com.perceptionit.configuration.inventory.processing.FileCollector getSMBFile INFO: In while/opt/dataloading/data/statisticalbss/4G_Updated_Region-Sheet-15-11-2019.xlsx to [B@fc12260b 0 8192 Dec 30, 2019 10:17:18 PM com.perceptionit.configuration.inventory.processing.FileCollector getSMBFile INFO: In while/opt/dataloading/data/statisticalbss/4G_Updated_Region-Sheet-15-11-2019.xlsx to [B@fc12260b 0 8192 Dec 30, 2019 10:18:18 PM com.perceptionit.configuration.inventory.processing.FileCollector getSMBFile INFO: In while/opt/dataloading/data/statisticalbss/4G_Updated_Region-Sheet-15-11-2019.xlsx to [B@fc12260b 0 8192

shahmeer arhsad
  • 49
  • 1
  • 2
  • 8
  • 1
    Please edit your question and add the log output as well as the info on the file you are trying to retrieve. – Robert Dec 30 '19 at 17:28
  • @Robert Log output added in the question. And I dont know much about the code. But it fetched an excel file and inserts data into a database table. I honestly do not have much knowledge about what the above code is being used for. – shahmeer arhsad Dec 30 '19 at 17:47
  • There is program called `smbclient` with FTP-ish features, it could be used for checking transfer-speed. – Lorinczy Zsigmond Dec 31 '19 at 06:28
  • @shahmeerarhsad The log does not match your description. If you encounter an endless loop there should be log entries starting with `In while...`. Anyway the buffer size of 8K you use is very small for transferring a file over network. I would recommend at least 128K. – Robert Dec 31 '19 at 12:16

1 Answers1

1

There is nothing to enter an infinite loop in that code piece. In the worst case scenario, the while loop will read one byte at a time and eventually exit the loop.

Looking at your logs, this is apparently not the case. It reads 8192 bytes (the size of the provided byte array) but time to read 8192 bytes is quite long, one minute: 10:17:18 PM - 10:16:18 PM.

I made a search on Google for SmbFileInputStream wait too long on RHEL and this answer shows up the first: JCIFS: file retrieval is too slow to be usable

Has quite some options for how to dig deeper and solve this problem.

r a f t
  • 411
  • 3
  • 9
  • Yes, this seems to be an issue with SMB JCIF library. Actually the code first copies a file from windows smb directory and places it in a directory. It is copying the file but with no content. Is there a way I can debug the SMB library that why it is failing to copy the contents of the file. – shahmeer arhsad Dec 31 '19 at 06:06
  • in one of the answers in the page I have posted, there is a mention to system property `jcifs.util.loglevel=3` to enable excessive logging. that might help – r a f t Jan 01 '20 at 17:11