Thanks for your inquiry.
a) A way of detecting that the document is to “hard” to open before we even try
b) Have Aspose fail in a more graceful way that does not take down the whole system.
I suggest you please use the same code in try catch block and handle the exception.
have tested the scenario and have managed to reproduce the same issue
at my side. For the sake of correction, I have logged this problem in
our issue tracking system as WORDSNET-10951. I have linked this forum
thread to the same issue and you will be notified via this forum thread
once this issue is resolved. We apologize for your inconvenience.
This message was posted using Notification2Forum from Downloads module by aspose.notifier.
Could you give me more information? What is the result of your fix?
My test results:
- With -Xmx256m:
+ 184.108.40.206: Fail after 17 seconds
+ 15.7.0: Fail after 4 seconds
- With -Xmx512m:
+ 220.127.116.11: Fail after 15 seconds
+ 15.7.0: Fail after 3 seconds.
- With -Xmx1024m:
+ 18.104.22.168: Fail after 60 seconds
+ 15.7.0: successful
So, with the fix, fail quicker and use memory more effectively?
Thanks for your inquiry. Yes, we have made performance improvements during transition from 13.9.0 to 15.7.0. Please note that performance and memory usage all depend on complexity
and size of the documents you are generating. While rendering a document to fixed page formats (e.g. PDF), Aspose.Words needs to build two model in the memory – one for document and the other for rendered document.
The process of building layout model is
not linear; it may take a minute to render one page and may take a few
seconds to render 100 pages. Also, Aspose.Words has to create APS (Aspose Page Specification)
model in memory and this may again eat some more time for some
documents. Rest assured, we’re always working on improving performance;
but, rendering will be always running slower than simple saving to flow
formats (e.g doc/docx).