When a BI-published concurrent program uses an XML Data Template to generate large quantities of data (for example the standard Account Analysis Report [XLAAARPT], in the Subledger Accounting application), the report may fail with the following error (in the log file):
Calling XDO Data Engine... ****Warning!!! Due to high volume of data, got out of memory exception...*** ****Please retry with scalable option or modify the Data template to run in scalable mode...*** ********************************************************************************
The problem is caused by the standard Java Concurrent Program, XML Publisher Data Template Executable [XDODTEXE], and the memory allocated to the program’s Java Virtual Machine (JVM) which is created at runtime by Oracle Applications.
There appear to be a number of ways to tackle this problem.
The quickest way seems to be entering the text string
-Xss2048k -Xmx2048m
…to the Executable Options field in the Concurrent Program definition screen:
-Xss: sets the JVM stack size (to 2MB in the above example).
-Xmx: sets the maximum memory (“heap size”) allocated to the JVM. In above example it is set to 2GB, which is the maximum usable memory for the 32-bit JVM used by the eBusiness Suite.
The JVM’s heap size can also be set (by a DBA) at site level, although I haven’t found it necessary to do this. To see what the value is set to, run the following query:
SELECT developer_parameters FROM fnd_cp_services WHERE service_id = ( SELECT manager_type FROM fnd_concurrent_queues WHERE concurrent_queue_name = 'FNDCPOPP' )
It is updated using SQL, and then the Concurrent Managers must be bounced:
UPDATE fnd_cp_services SET developer_parameters = 'J:oracle.apps.fnd.cp.gsf.GSMServiceController:-mx2048m' WHERE service_id = ( SELECT manager_type FROM fnd_concurrent_queues WHERE concurrent_queue_name = 'FNDCPOPP' )
Oracle also recommend creating a Scalable Flag for the concurrent program (see Metalink Note 737311.1), but, again, I haven’t found it necessary to do this.
The scalability option is set by performing these steps:
Resp: System Administrator
Nav: Concurrent > Program > Define
Query back the concurrent program, and add a parameter called P_SCALABLE_FLAG:
Enabled: Yes
Value Set: yes_no
Default Type: Constant
Default Value: Y
Display: No
Token: ScalableFlag (this value is case sensitive)
You can also create a parameter called P_DEBUG_FLAG so that the log file includes the following:
- Report SQL
- Calling XDO Data Engine and the Scalable mode on
The parameter should have the following values:
Enabled: Yes
Value Set: yes_no
Default Type: Constant
Default Value: Y
Display: No
Token: DebugFlag (this value is case sensitive)
Other memory related issues…
If the concurrent program finishes with a Warning status, and the following message appears in the log file:
+------------- 1) PUBLISH -------------+ Beginning post-processing of request 4099006 on node C-ERP-DEVORA01 at 30-MAY-2012 10:31:15. Post-processing of request 4099006 failed at 30-MAY-2012 10:31:16 with the error message: One or more post-processing actions failed. Consult the OPP service log for details. +--------------------------------------+
…consult the OPP service log file which is found in $APPLCSF/$APPLLOG, and which is called something like FNDOPP107254.txt.
(The contents of the OPP service log file can also be viewed from the Applications, Resp: Systems Administrator, Nav: Concurrent > Manager > Administer, select the “Output Post Processor” and click on the Processes button, choose the Active process and click on the Manager Log button.)
If a java.lang.OutOfMemoryError appears for your concurrent request ID, configure the XML Publisher Administrator Configuration settings as follows:
Resp: XML Publisher Administrator
Nav: Home > Administration > Configuration > Properties > General > Temporary Directory
Check that the temporary directory location (/tmp, in the above example) is at least 5GB or 20 times larger than largest XML data file that you generate. You can check the available space using the UNIX command df -h, as follows:
server1$ df -h /tmp Filesystem size used avail capacity Mounted on swap 34G 17M 34G 1% /tmp
It may also be necessary to set some FO Procesing properties on this page (although I haven’t had to do this, and the settings may require the application of one or two BI-Publisher-related patches – see Metalink Note 737311.1):
Use XML Publisher’s XSLT processor = True
Enable scalable feature of XSLT processor = False
Enable XSLT runtime optimization = True
For further information, see Metalink Notes:
737311.1: “How to Configure the Account Analysis Report in Release 12 for Large Reports”.
1410160.1: “Troubleshooting Known XML Publisher and E-Business Suite (EBS)”. “Integration Issues