SSLPrematureCloseException occurs when read a big file using FTPInputStream

Question

Hi!

I use SSLFTPClient to put/get files from FTPS server. In most cases it works fine. But sometimes I get the next exception when some threads download different files of big size (about 1 Gb) using FTPInputSream reading and processing line by line. This happens in the middle of reading process file, not on starting.

Caused by:

com.enterprisedt.net.puretls.SSLPrematureCloseException: Short read
at com.enterprisedt.net.puretls.ad.a(SSLopaque.java:105)
at com.enterprisedt.net.puretls.x.a(SSLRecord.java:155)
at com.enterprisedt.net.puretls.y.a(SSLRecordReader.java:68)
at com.enterprisedt.net.puretls.r.read(SSLInputStream.java:107)
at java.io.DataInputStream.read(DataInputStream.java:149)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
at com.enterprisedt.net.ftp.FTPClient.readChunk(FTPClient.java:4091)
at com.enterprisedt.net.ftp.d.read(FTPBinaryInputStream.java:144)
at com.enterprisedt.net.ftp.FTPInputStream.read(FTPInputStream.java:145)

Answer 1

'Short read' means that the client has lost the connection with the server.  These can be very hard to diagnose, particularly when they're intermittent and the transfers are huge.

Have you implemented a robust retry strategy?  In particular, I'd recommend reconnecting and resuming the transfer from where you left off.  This is more tricky than usual for you since you're processing a stream in real-time, but it shouldn't be too hard.  FTPInputStream has a constructor that takes an offset, so you just need to set that to the size of the remote file when you resume.  Since you're (presumably) parsing lines of text, you'll need to buffer any uncompleted lines of text between retries so that you can prefix them to the first line of the resumed stream.

I realise this does directly answer the question that you asked, but for file-transfers as large as that, having a robust retry strategy is really essential since you can't stop interruptions occurring entirely.

Comments

But I don't understand why there is no this error when I retrieve the full file instead using stream? This error are reproduced stable when I use FTPInputStream. Early I used FTPSClient from Apache and all worked ok. I don't think that I have stable problems with FTPS server otherwise I would noticed it earlier.

---

I don't understand why this is the case either since the underlying code is the same.  I mean the file download code is just using a file stream.  Could there be a delay in part of your code that causes the server to time out the connection perhaps?