Customers using Export to Excel (data only) to export large amounts of data via either OOTB or custom portlets built off our own data providers are running into java heap OOM errors. These customers all have in common (so far) are instance rights granted via OBS groups for the user running the export, and grid portlets using many columns and many rows. The OOM condition can be triggered by either running concurrent large exports (so far seen with 10k or more), single large exports approximately 100k or more and by executing an export request waiting and then triggering the request to run again and again by hitting the browser back button and starting the request over again.
We currently do not recommend customers use any Export to Excel from a grid portlet as a reporting replacement. However, we do not prevent this so therefore we have many large customers who have relied upon these grids in 8.x and before as reports who are now upgrading to 12.1.x and experiencing performance issues. We also warn customers not to use the back button... but we don't prevent that either. Customers upgrading from 8.x to 12.1.x are now running into memory starvation issues after upgrade as the queries to produce the export now produce a larger file upon output and tap into our data provider security.
Steps to Reproduce:
Expected Result: Export to Excel to remain close to the same performance wise pre-12.1
Actual Result: Export to Excel time has increased
Use global security, reduce the number of rows to export (lower limit), reduce or limit columns depending upon data, increase hardware to allow for more system resources
Release: ESPCLA99000-13.2-Clarity-Extended Support Plus