PPTX File Conversion Service causes high CPU and/or memory usage because of Aspose Slides InterruptMonitor is not implemented

Summary

Uploading some PPTX files to Confluence can cause a high CPU/Memory usage which causes the instance to crash or become unavailable. Although this bug was fixed CONFSERVER-52279, the Aspose Library for Powerpoint Slides being used doesn't implement an InterruptMonitor to stop that thread from leaking memory or CPU resources

Steps to Reproduce

1. Upload a large Powerpoint file
2. Wait for the preview to generate
3. At the same time monitor the CPU and memory usage on your instance

Expected Results

Confluence should be able to handle the conversion of a PPTX file and if it reaches a certain threshold it should kills/quit the conversion.

Actual Results

Confluence becomes unresponsive. High CPU/Memory usage starts showing and we see this in the thread dumps:

Thread Dumps

In the thread dumps, you would see a long running thread that looks like this

"conversion-thread-2-internal" #108270 daemon prio=5 tid=0x00007f070068e000 nid=0x7227 runnable [0x00007f05cb539000]
   java.lang.Thread.State: RUNNABLE
	at sun.font.T2KFontScaler.getUnitsPerEMNative(Native Method)
	at sun.font.T2KFontScaler.getUnitsPerEm(T2KFontScaler.java:227)
	- locked <0x0000000662839a10> (a sun.font.T2KFontScaler)
	at sun.font.FileFont.getUnitsPerEm(FileFont.java:247)
	at sun.font.SunLayoutEngine.layout(SunLayoutEngine.java:161)
	at sun.font.GlyphLayout$EngineRecord.layout(GlyphLayout.java:685)
	at sun.font.GlyphLayout.layout(GlyphLayout.java:466)
	at java.awt.Font.layoutGlyphVector(Font.java:2637)
	at com.aspose.slides.internal.j7.int.do(Unknown Source)
	at com.aspose.slides.internal.j7.int.while(Unknown Source)
	at com.aspose.slides.internal.j7.int.catch(Unknown Source)
	at com.aspose.slides.internal.j7.int. (Unknown Source)
	at com.aspose.slides.internal.ek.public.do(Unknown Source)
	at com.aspose.slides.internal.ek.public.do(Unknown Source)
	at com.aspose.slides.internal.dc.short.do(Unknown Source)
	- locked <0x00000007bc07ea70> (a java.lang.Object)
	at com.aspose.slides.cu.do(Unknown Source)
	at com.aspose.slides.ah0.if(Unknown Source)
	at com.aspose.slides.ah0.do(Unknown Source)
	at com.aspose.slides.ah0.do(Unknown Source)
	at com.aspose.slides.ah0.do(Unknown Source)
	at com.aspose.slides.ah0.do(Unknown Source)
	at com.aspose.slides.ah0. (Unknown Source)
	at com.aspose.slides.TextFrame.do(Unknown Source)
	at com.aspose.slides.TextFrame.do(Unknown Source)
	at com.aspose.slides.TextFrame.char(Unknown Source)
	at com.aspose.slides.ahw.do(Unknown Source)
...

Heap Dumps

In the heap dump, you would see the following pattern

Workaround

The current workaround is to upgrade to Confluence 6.10 or newer to benefit from the Sandbox feature for Confluence Data Center. You can read more about this in this documentation Document Conversion Sandbox for Confluence Data Center

If you are running a server instance that is affected by the bug, you can disable the file conversions service as follows until it is possible to upgrade:

• Disable the file conversions service

Mitigation Plan

If you are unable to upgrade to Confluence 6.10 and above and you would like to limit the impact of this issue on your instance, you can limit the number of conversion threads in your instance by adding the following JVM argument

-Dconfluence.document.conversion.threads=3

Please note that this JVM argument doesn't remove the risk of one thread causing this issue again, but it reduces the possibility of this issue having a bigger impact on your instance.