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

Free Support Forum - aspose.com

Aspose v1.7.4.0

We are currently using Aspose.Cells v1.7.4.0 for rendering Excel Reports (Excel 2000 SP1) and Websphere 5.1. For large reports we are facing JVM heap dumps due to Out of memory exceptions.

Can you pls clarify if there is a limit for Aspose rendering to Excel? Is this a known issue in v1.7.4.0?

As per the following Post the Aspose excel memory issues have been resolved in v2.1.2. We tried the Trial version but did not observe any change in Memory issues. Can you pls clarify if upgrading to new version would help and provide any relevant reference material?

http://www.aspose.com/community/forums/218867/memory-problems-when-saving-a-large-formmatted-excel-file-using-aspose.cells/showthread.aspx

Thank you and have a good weekend,
Deepa Parikh

Hi Deepa,

We did significant improvements regarding performance in the recent versions. Well, rendering larger reports,
you should have sufficient memory assigned/allotted to JVM to process the reports.
Kindly make sure that you have provided and extended the JVM memory
appropriately to process the file.

Following is the command
line you may use on the Windows XP command prompt to extend the JVM
memory accordingly:

e.g

java -Xms1024m -Xmx1024m
MyTestProgram


We now have released v2.2.0, please give it a try: http://www.aspose.com/community/files/72/java-components/aspose.cells-for-java/entry233107.aspx


If
you still could not evaluate, kindly provide us more details with
sample codes, template file(if you have) etc. We will check it soon.

Thank you.

Hi Amjad,

Thanks for your response. We are primarily using the aspose "importResultSet(rs, 0, 11, false)" method to render large amounts of data to Excel (11,000-30,000). See attached code snippet for reference. Due to the large amounts of data we have been experiencing JVM heap dumps due to Aspose Out of Memory exceptions.

Here are the steps we have tried so far for tuning the reports without much progress:

1. Tested trail version v2.2.0 but still got the JVM heap dumps due to Aspose. Do we need to test the Licensed version or make code modifications? Is it different from trial version. Can you also highlight the improvements in v2.2.0 design vs v1.7 in regards to rendering to excel.

2. Increased JVM memory settings from Min 50 MB, Max 256 MB to Min 512 MB,Max 1.5 GB: Improved performance for single report but still get memory dumps for concurrent reports.

3. Chunking the data. Instead of processing all the rows at a time we have broken down the resultset to process 500 rows at a time - Improved performance for single report but still get memory dumps for concurrent reports.

Pls advice ASAP. This is a production system issue and appreciate your prompt help. Can we set up a quick call with the Development team.

Thanks,
Deepa

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Hi Amjad,

Some additional query from our team:

1. We are able to export large reports doing single user testing using aspose. But when we run continue single user and single report testing for the same report multiple times..ie if we run the large report 7-8 times in succession we notice JVM heap dumps due to aspose out of memory exceptions. See the exception details below.

2. Another question is - if we are able to load the data from resultset into aspose cells without out of memory error, why does it happen during while saving the workbook?

Request your prompt help as we are facing these severe performance issues in Production and need to resolve them at the earliest. We hope to get a solution with guidance from the Aspose team ASAP.

ASPOSE EXCEPTION:

StackTrace: java.lang.OutOfMemoryError

at com.aspose.cells.bl.a(Unknown Source)

at com.aspose.cells.bl.b(Unknown Source)

at com.aspose.cells.bl.b(Unknown Source)

at com.aspose.cells.o.a(Unknown Source)

at com.aspose.cells.o.b(Unknown Source)

at com.aspose.cells.o.u(Unknown Source)

at com.aspose.cells.o.a(Unknown Source)

at com.aspose.cells.Workbook.save(Unknown Source)

at com.aspose.cells.Workbook.save(Unknown Source)

at kpmg.estars.reports.ReportListHelper.saveDataToReportWorkBook(ReportListHelper.java(Compiled Code))

<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

Thanks,

Deepa

Hi Deepa,

Thanks for providing us further details.

We will look into your case and get back to you soon.

Thank you.

Hi Amjad. Thanks for the update. When can we expect as revert?

Thanks,
Deepa

Hi Deepa,

For the memory cost issue, it mainly depends on the dataset's size to import into the workbook if you have not used other memory consumed operations such as inserting drawing objects or applying many different styles for cells. And, Aspose.Cells for Java is a pure java component, there is not any special operation to allocate and use memory by itself and everything is managed by JVM's GC mechanism. So, for your questions:
1) We are able to export large reports doing single user testing using aspose. But when we run continue single user and single report testing for the same report multiple times..ie if we run the large report 7-8 times in succession we notice JVM heap dumps due to aspose out of memory exceptions. See the exception details below.

I think maybe it is because the report you created just causes the JVM to reach the threshhold of memory. As you know, the GC operation of JVM is not so accurate and cannot be exactly same for every one of several repeated tasks. And, would you please check whether there are some global objects in your enviornment that may be created or cannot be destroyed by GC when you create the same report multiple times.
2) Another question is - if we are able to load the data from resultset into aspose cells without out of memory error, why does it happen during while saving the workbook?

When saving the workbook, some extra memory will be needed to hold some middle data structures such as the buffer for resultant file data. If the used memory has been near to the threshhold of JVM after importing data, OutOfMemory exception may be encountered when saving the workbook.
And for your questions in your prior post:

1) Tested trail version v2.2.0 but still got the JVM heap dumps due to Aspose. Do we need to test the Licensed version or make code modifications? Is it different from trial version. Can you also highlight the improvements in v2.2.0 design vs v1.7 in regards to rendering to excel.

Well, there should be not much difference between trial and licensed versions for memory cost. There are many differences between v2.2.0 and v1.7 such as fixed bugs, enhancements or new features are incorporated. Regarding memory cost, one significant improvement is for applying large amount of styles for the cells.
2) Increased JVM memory settings from Min 50 MB, Max 256 MB to Min 512 MB,Max 1.5 GB: Improved performance for single report but still get memory dumps for concurrent reports.

Well, concurrent reports will surely require more memory than a single one. For memory cost, I think it is just the summation of memories that every single one needs.
3) Chunking the data. Instead of processing all the rows at a time we have broken down the resultset to process 500 rows at a time - Improved performance for single report but still get memory dumps for concurrent reports.

Would you please explain it more? Do you mean that splitting one large resultset into multiple smaller resultsets and calling "importResultSet()" many times will improve the performance? It is strange because we think the memory cost should depend on the total dataset imported into the Workbook object and has nothing to do with the operation count of importing it.
Do you have other operations on the Workbook except importing plain data? By our test, 500M memory is enough for importing simple data(such as Date, Number, String) for about 300,000 cells. If your dataset is simple too but it costs too many memories, would you please give us a simple test project and we will check it soon to see whether we can make some improvements for it.


Thank you.

Hi Amjad,

Thanks for your detailed response.

We are running much larger reports (compared to the 300k number given by Aspose) and observing memory leaks due to aspose. Based on the code snippet provided can your team try to run the import to excel and check on the memory leaks issue for Aspose. This is independent of the JVM memory utilization and would need to be fixed in any case.

Will also share a test project with your team soon so you'll can test and replicate the issue.

We are in the process of purchasing the Priority Support for quicker response & hope to get it soon.

Thanks and Have a good weekend,
Deepa

Hi Deepa,

Are you able to replicate the issue by creating your test project, we are still waiting for it. After we get your test project here, we will analyze and investigate your issue.

Thank you.