We’ve observed a file handle leak in the Aspose.PDF for Java v19.5 PdfFileEditor class when using the concatenate method.
The leak only occurs when UseDiskBuffer and/or IncrementalUpdates are set to true.
None of the input or output files to the concatenate method will have their file handles released until the JVM terminates.
For example, in the code below:
public boolean concatenate(List<String> fileList, String outputFile)
PdfFileEditor editor = new PdfFileEditor();
Aspose will leak file handles for every file in fileList, as well as outputFile’s file handle. It will not release them until the JVM terminates.
Note: Was able to successfully work around this by using the PdfFileEditor.concatenate(InputStream, OutputStream) method override and terminating the handles on the stream objects within our code. Please note that the Streams version of the method cannot make use of disk buffers; we had to implement our own. The bug remains in the PdfFileEditor.concatenate(String, String) method signature.
It is good to know that you managed to resolve your issue. However, we have logged an investigation ticket as PDFJAVA-38607 in our issue tracking system on the basis of information you have shared. We will further look into this scenario and keep you posted in case we have additional updates regarding ticket resolution. Please spare us little time.
We are sorry for the inconvenience.
Our workaround was unable to meet our customers’ needs. We had to revert to using PdfFileEditor.concatenate(String, String) with a disk buffer. We’re attempting a second workaround where we duplicate every file involved in concatenation, concatenate them, then delete or move them within our Java program.
This will allow our application to work, but we’re concerned that we’ll end up leaking thousands of file handles that never get cleaned up - Even if we delete the files, that doesn’t mean Aspose will release its handles on them (EDIT: Confirmed it does NOT release handles after delete). Can you provide any advice on possible fixes or workarounds to this issue in the short term? The only one we’re aware of so far is to restart our program, but I’m hoping we don’t have to take that route (it’d add a large burden on myself to develop a viable restart procedure, along with a significant delay in our timeline).
We have recorded your concerns and will definitely consider them during issue investigation. It would also be helpful if you can please provide the environment details where you are using API (OS Name and Version, JDK Version, etc.). Also, please provide some sample PDF documents which can be used for testing and with which you are noticing mentioned issue.
@asad.ali I’ve confirmed this on Java 8 (several updates from 161 to 211) across Windows 10, Windows Server 2016, Windows Server 2012, and Windows Server 2008 (various versions of each). I encountered it on Aspose.PDF versions 19.2 and 19.5.
Far as I’m able to tell, it can be reproduced on any given PDF… Many of our test PDFs are generated with Aspose in the first place. I’ll attach a couple files in a zip, but feel free to use your own.
PDFs.zip (85.0 KB)
Thanks for sharing requested information.
We will further update you as soon as some additional updates are available.
The issues you have found earlier (filed as PDFJAVA-38607) have been fixed in Aspose.PDF for Java 19.6.