Any update on this issue?
The linked ticket ID PDFNET-44613 is pending for the analysis and not resolved yet. We will investigate as per the development schedules, and notify you once it is fixed.
We have not received any updates about this issue and this is affecting the performance of our software, please advice to a solution or a work around. We need to understand the cause of the slow performance we are experiencing when rendering our documents using Aspose 18.4 that was supposed to have fixed the memory allocation.
Thanks
The linked ticket ID PDFNET-44613 has just been identified and pending for the analysis. It could take time because there are other high priority tickets in the queue. In order to escalate the priority, we recommend you to post this ticket Id in the paid support forum. Please refer to this helping link: Aspose support options
any update about this issue?
I am afraid that earlier logged issue is not yet resolved. Please note that it has been logged under free support model and will be investigated and fixed on first come first serve basis. There is already large number of issues in the queue which are pending and were logged prior to your issue. As soon as we have some definite updates regarding resolution of your issue, we will surely inform you. Please be patient and spare us little time.
We are sorry for the inconvenience.
We are also experiencing an issue with memory leaks when converting html to pdfs.
We are trying to convert html pages to pdfs on mass but with each conversion the memory in use goes up until the RAM on the server is maxed out and the program crashes. This is a major issue as the project effectivly can’t be completed until this is resolved. Is there any indication on when this will be fixed?
Thanks for your inquiry.
The issue has already been logged in our issue tracking system. However, it is still pending for a resolution due to long queue of pending issues. We have recorded your concerns and will definitely consider them while resolving the issue. As soon as we are in position to share any reliable ETA, we will surely inform you. Please spare us little time.
We are sorry for the inconvenience.
Is there any update on when this will be looked at? Our client bought the licence specifically for this project and they are currently unable to make any use of it due to this issue.
Thanks for your inquiry.
As shared earlier in the thread that issue is pending for analysis due to low priority and long queue of previously logged issues, I am afraid we are not in position to share any reliable ETA. Furthermore, if issue is a blocker for you and you need to get it resolved urgently, we request you to please check paid support option where issues are resolved on priority basis. As soon as we have some updates regarding resolution progress, we will surely inform you.
We are sorry for the inconvenience.
The issues you have found earlier (filed as ) have been fixed in this update. This message was posted using BugNotificationTool from Downloads module by MuzammilKhan
The above link is for v19.1 of Aspose.Words for JasperReports… ?? Is that related to Aspose.PDF shared libraries? As far as I can see, the high memory allocation issue still exists in Aspose.PDF for .NET v19.11. Every time a TextFragment is added to a paragraph, I see a memory jump of 1-3MB. A very small pdf with minimal text and a single page consistently allocates 2-300MB of unreleased memory based on my diagnostic tools. A 2-page PDF with several paragraphs allocates closer to 600MB. The memory usage alone would not be so alarming if it were eventually released, but I’m seeing this persist until a full application restart. Cleaning up any streams (like images) generated in our own code does not significantly help - the main area I’m seeing unreleased memory usage is TextFragment generation and manipulation.
Thanks for posting your inquiry.
The bug fix notification was related to Aspose.Words for JasperReports and it was posted due to some technical fault. We truly apologize for the misunderstanding. Furthermore, we have logged your concerns under the original logged ticket and will definitely take care of them during investigation. We will surely provide an update within this forum thread when issue is resolved. Please spare us little time.
We are sorry for the inconvenience.
The issues you have found earlier (filed as PDFNET-44613) have been fixed in Aspose.PDF for .NET 20.2.
We are still seeing these issues in Aspose.PDF for .Net 20.4. Can you confirm if there are any other outstanding bugs causing this please?
The issue was resolved in 20.2 version of the API. Would you please confirm if this issue is happening again in 20.4 as regression?
It seems to still be happening in 20.4 and 20.2. The memory does not get released after conversion from HTML to PDF, even though any objects we use are disposed of.
We have logged your concerns along with the ticket and will surely re-investigate it. We will let you know as soon as we have some updates in this regard. Please spare us some time.
We did some memory profiling on our server. Please see attached image showing objects held in memory if this helps to further identify the issueAsposeMemoryProfile.PNG (110.9 KB)
We have logged the provided information along with the ticket and will share updates with you as soon as we have some.