The default settings for LiveCycle are not optimal for the processing of large documents. Large documents can be defined as anything that is larger than 50 MB.
Java Heap Size
You might need to set heap size bigger than 1.2 GB If that is the case, you cannot use 32-bit JDKs on Windows or Linux. You need to move to a complete 64-bit environment with a 64-bit OS, a 64-bit JDK along with a 64-bit appserver.
A common mis-conception is that LiveCycle will be able to use all of the RAM on a server. But LiveCycle only has access to what the JVM has access to. And that is limited by its configuration which is usually 256 MB unless changed. The JVM argument that controls the minimum memory is -Xms and the same for the maximum is -Xmx. If -Xmx is set to 1 GB, LiveCycle will only get to use 1 GB even if your server has 8 GB of RAM. The JBoss and WebLogic Turnkey Installations of LiveCytcle set this to 1 GB.
Appserver Transaction Timeout
Most application servers have a transaction timeout that is configurable. You need to change this to a higher value. For example, we recently had to set this to 30 minutes for a 500 MB Microsoft Word document that was being converted to PDF by PDF Generator ES.
For JBoss, this configuration is in the %JBOSS_HOME%\server\all\conf\jboss-service.xml Using a reliable text editor, (avoid Notepad), increase the value of the TransactionManager’s TransactionTimeout attribute from 300 seconds to a higher value. Re-start the appserver instance. In JBoss EAP 5.1 that ADEP comes with, change the value for com.arjuna.ats.arjuna.coordinator.txReaperTimeout in the file jbossts-properties.xml
For WebSphere, using the WebSphere Admin Console, navigate to the appserver instance hosting LiveCycle. In ‘Container Services’->’Transaction Service’, set the values for ‘Total transaction lifetime timeout’ and the ‘Maximum transaction timeout’, and re-start the appserver instance.
ORB Service Request Timeout
This needs to be configured to a high enough value. The LiveCycle installation and administration guides provide details on how to do this for your J2EE appserver.
SOAP Request Timeout
If using SOAP, this needs to be configured to a high enough value in IBM WebSphere. Edit $WEBSPHERE_PROFILE_ROOT/properties/soap.client.props file in a
text editor and change the property com.ibm.SOAP.requestTimeout.
LiveCycle Orchestration Timeout
This needs to be configured to a high enough value. Using Workbench, navigate to the active version of the orchestration, right-click the mouse, and choose ‘Properties’ to get the appropriate dialog.
LiveCycle Service Timeout
Many LiveCycle services have timeout settings of their own. For example, for PDFGenerator, the PDFGConfigService lets you configure this. Navigate to Services->Applications and Services->Service Management. Locate PDFGConfigService and click it. Change the value of ‘Server Conversion Timeout’ from the default 270 seconds. Save and then re-start the appserver instance.
For Output ES, navigate to Services->Applications and Services->Service Management. Filter the list by choosing the category ‘Output’ from the dropdown list. Click on ‘OutputService: 1.1’. In the ‘Configuration’ tab, change ‘Transaction timeout’ from the default 180 seconds to a higher number as required. Save and then re-start the service.
Default Document Max Inline Size
Set this value to a number higher than your largest document. More details are available here. Please note that setting this to 50 MB or higher will blow your Java heap and crash the appserver if you don’t set the JVM heap size correspondingly higher.
Large documents require additional diskspace for temporary File I/O. The filesystem that hosts the ‘LiveCycle Temporary Folder’ requires several GB of disk space if processing a large number of BIG documents. If some of those transactions timeout or throw an exception, this filesystem runs the risk of running out of diskspace because of orphaned files. Periodic cleanup might be required. The folders of interest are %LC_TEMP_FOLDER%\AdobeDocumentStorage\local\ and %LC_TEMP_FOLDER%\pdfg-livecycle\.
Large document conversion is CPU-intensive. Conversion of Microsoft Office documents to PDF is single-threaded. As a result, concurrent mulitple coversion requests will queue up unless the solution is load-balanced across multiple servers. The 500 MB Word document conversion consistently used 3 GHz of CPU cycles for over 15 minutes.