OOM aspose-html 26.2

Steps to Reproduce:

Expected Result:

  • mht to pdf conversion success. generate output.pdf file

Observed Result:

  • Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread “main”

@divine1

We are unable to find the source code at given link. Could you please share .zip of the code here?
image.jpg (57.2 KB)

Test1:

Observation: received OOM and program remains hung for more than 10minutes

<dependency>
            <groupId>com.aspose</groupId>
            <artifactId>aspose-html</artifactId>
            <version>26.2</version>
            <classifier>jdk21</classifier>
</dependency>

image.png (181.5 KB)

Test2:

Observation: program completed in 231 seconds. but the generated output doesnot seem to look good. can you make any improvements to it?

<dependency>
            <groupId>com.aspose</groupId>
            <artifactId>aspose-html</artifactId>
            <version>26.6</version>
</dependency>

console log
image.png (284.7 KB)

output pdf
DURATION.pdf (8.9 MB)

class to execute: org.epiqpoc.mainhtml.MainHtml

source code:
aspose-content - Copy.7z (36.0 KB)

you need to add aspose license in the program. i removed the aspose license from the attached zip file as the license file belongs to epiq.

i have created new ticket to discuss about alignment issues/ output content issues
JAVA - aspose-html 26.6 - output does not have content in proper form - Free Support Forum - aspose.com

Please close this ticket as i don’t see OOM problem anymore with latest version
OOM aspose-html 26.2 - Free Support Forum - aspose.com

We are continuously working on both performance optimization and further improvements to rendering quality.

Regarding the execution time you mentioned, we would like to point out that when benchmarking Java applications, it is important to take the initial JIT warm-up phase into account, as the first few executions may be noticeably slower than subsequent ones.

Based on our measurements, performance typically improves significantly after approximately 5–10 iterations. Therefore, to obtain more representative benchmark results, we recommend performing 5–10 warm-up runs before measuring performance and collecting timing results only after the warm-up phase has completed. If reducing cold-start time is important for your use case, you may also consider using Coordinated Restore at Checkpoint (CRaC): https://crac.org/.

More detailed recommendations on benchmarking Java applications correctly, including application warm-up recommendations, are available in our article:

We are also continuously working to further improve rendering quality and regularly deliver enhancements in this area.

We kindly ask for your patience while we continue these improvements. Please rest assured that your feedback has been noted and taken into consideration. Thank you for your understanding.