We're sorry Aspose doesn't work properply without JavaScript enabled.

Free Support Forum - aspose.com

Aspose PDF/Word Java leaving open descriptors on latest respective versions


We have been using Aspose words/pdf for Java (licensed Aspose total). We have recently come to the observation that aspose libraries might be leaving open file descriptors for our java process, and these FDs remain open even when the file is deleted with “(deleted)” under /proc//fd .

The only way to close/ terminate such open FDs is to restart the java process.

Following is a code example of our implementation of creating a pdf from a base 64 content.

AsposeFileDto createPDFAspose(String content) throws DocumentException, IOException
AsposeFileDto output= new AsposeFileDto();
byte[] byteValue;
String dest = “resources/”+ UUID.randomUUID().toString() + “.pdf”;

	byteValue = java.util.Base64.getDecoder().decode(content.getBytes());
	com.aspose.pdf.Document pdfDocument;
	ByteArrayInputStream pdfFile = new ByteArrayInputStream(byteValue);
    pdfDocument = new com.aspose.pdf.Document(pdfFile);
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    com.aspose.pdf.Document pdfDocument1;
    pdfDocument1 = new com.aspose.pdf.Document(dest);

	return output;	

note: that both pdf document variables were closed.

Sample document attached.
8 Years O&M Amendment Agreement [Executed Version 26-05-2015] compressed_compressed - Copy (7).pdf (357.1 KB)

Prompt response with valuable insight and possible solution will be highly appreciated.


Unfortunately, we are unable to execute your code. Please create a sample Java application (source code without compilation errors) that helps us to reproduce your problem on our end and attach it here for testing.

Please share the complete steps how are you checking these values.

I will provide a simple java application for you debugging with simple pdf creation via base64 content, mean while

We are observing open descriptors via ls -ltr on the JVM process id location in /proc/PID/fd folder.

Normally FDs here open and close, but documents created through aspose have their descriptors visible here untill we restart the JVM. Ideally they should not appear in /proc/PID/fd location after the program has completed and the close() has been called within the code as done and shared below



Please download the sample project with the implementation of the code shared before. The code should leave open file descriptors as observed on our Linux RedHat environment.

Waleed Khalid.

We need your response earlier please to fix the problem on production systems as due to this, we need to restart the application on daily basis.


We have logged an investigation ticket as PDFJAVA-41456 in our issue tracking system. You will be notified via this forum thread once this issue is resolved.

We apologize for your inconvenience.

A post was split to a new topic: Aspose Word Java leaving open descriptors on latest respective versions


Thanks for your response. We will be thankful if we get response earlier as we need to restart production application server daily basis putting bad impact for business and also need to involve our infra teams.



We will investigate the issue and share an update on it with you via this forum thread.

Tahir, do we have any update on this issue?


Your issue is pending for analysis at the moment. Once we complete the analysis of your issue, we will then be able to provide you an estimate.

Any positive news Tahir?


Unfortunately, there is no update available on this issue at the moment. We will inform you via this forum thread once there is any news available on it.


Please expedite a fix for this as soon as possible. Its been nearly 3 months since the issue was reported and open descriptors really choke the system once they cross a certain threshold against the ulimit parameter.

We are eagerly waiting for a fix.

Waleed Khalid


It is to inform you that the issue which you are facing is actually not a bug in Aspose.PDF. So, we have closed this issue (PDFJAVA-41456) as ‘Not a Bug’.

We investigated your code in different environments (macOS, Ubuntu and Red Hat) and found some differences.

On the Red Hat OS (Red Hat Enterprise Linux release 8.4), remains open file descriptors, in our case that was only fonts. But this does not apply to the Aspose.PDF library for the reason that they are left open by Java itself. Aspose.PDF library only invokes the method for getting the list of available fonts and cannot close these font files.

For example, you can try to run following code snippet to got the open FDs:

GraphicsEnvironment localGraphicsEnvironment = GraphicsEnvironment.getLocalGraphicsEnvironment();
java.awt.Font[] fonts = localGraphicsEnvironment.getAllFonts();


Thanks for the update, We too are using font in our code as well for setting template. Something like

textStamp = new com.aspose.pdf.TextStamp(new com.aspose.pdf.facades.FormattedText(“Heading”, java.awt.Color.BLACK, java.awt.Color.WHITE, com.aspose.pdf.facades.FontStyle.Helvetica, com.aspose.pdf.facades.EncodingType.Winansi, true, 14));

For Long we believed that closing streams was the issue but as you suggested its something different altogether.

Please specify a workaround for remedy of this FD issue or a fix, be it Aspose java or fonts for that matter. Since last 2~3 months we have been regularly restarting JVM to keep FD count within check, but this too is getting tiresome for the teams as the load increases on PDF generation service using Aspose.

Waiting for a prompt response for resolution of this long running thread.

Waleed Khalid


We investigated this issue in detail and noticed that it is not related to Aspose.PDF. Could you please share following detail along with complete steps that you are following to reproduce the same issue at our end?

  • Java version
  • Linux Red Het version
  • Screenshots with names of opened FDs
  • Other details represent the issue in our environment

Thanks for your cooperation.