Preventing java.lang.outOfMemory conditions in BusinessConnect

Preventing java.lang.outOfMemory conditions in BusinessConnect

book

Article ID: KB0092648

calendar_today

Updated On:

Products Versions
TIBCO BusinessConnect -
Not Applicable -

Description

Description:
Environment

TIBCO BusinessConnect 5.X

Symptoms:

Occasionally, BusinessConnect will fail to process transactions, and throw a java.lang.outOfMemory exception in the BusinessConnect*.log file.  This may cause the engine to stop working.

Cause:

OutOfMemory exceptions are generally caused by the BC engine processing too many tasks in parallel, or by not having enough memory configured for the BC engine to process the tasks assigned.

Resolution:

There are two things to consider when doing memory tuning with BC.  The first is the Java memory parameters "Maximum Heap Size (MB)" and "Java Thread Stack Size (KB)" .  By default the Maximum heap size is set to 512 MB.   For BC protocols other than EDI, the Max Heap Size can be set to as high as 1500 MB in 32-bit Java Runtime Environments (JRE), and 3000 MB in 64-bit JREs.  For the EDI protocol, a maximum value of 1024 MB is recommended for 32-bit JREs and 2500 MB for 64-bit JREs, as the EDI protocol uses a set of native libraries that occupy separate C heap space by default.

The Java Thread Stack size controls how much memory is allocated to a thread when it is created. By default it is 512 KB.  This value can be lowered to 256 KB (except HP-UX which is 272KB) without issue.

These memory parameters are configurable by engine under the "Process Configuration" of the engine deployment in the Administrator.

The second area to consider with BC memory tuning is the number of jobs that are being processed by BC in parallel.  By default, all of the process starters in BC have their "Max Jobs" parameter set to 0, which means that BC will try to process all jobs immediately when received from an event source.  Under periods of heavy inbound and outbound requests, the BC engine may require more memory than is available in the Java Virtual Machine (JVM).  You can limit memory usage by controlling the number of jobs by changing the "Max Jobs" parameter for the following processes:

- Gateway/BMH/Outbound/From-Back-Office/&ltRV | JMS>/Receive Request

This is the process that picks up outbound requests from BW.  By setting this parameter to a non-zero value, you can control the number of outbound jobs that can be processed by the BC engine at any given time.

- Gateway/MSH/Inbound/From-DMZ/RV Receiver

This is the process in the interior server that starts the processing of inbound requests from the DMZ.  By setting this parameter to a non-zero value, you can control the number of inbound jobs that can be processed by the interior BC engine at any given time.

- Gateway/DMZ/From-Partners/FILE/Receiver

This parameter controls the number of files that will be picked up by the inbound file poller in the DMZ per polling cycle.  By setting this to a non-zero value, you can control how many inbound files get sent to BC during a polling cycle.

- Gateway/BMH/Outbound/From-Back-Office/&ltRV | JMS>/Receive Response

This is the process that picks up outbound responses from BW processes that were triggered by inbound request from BC.  Since these responses tend to be synchronous, TIBCO recommends that this parameter be left at zero.

These parameter are configurable under the "Advanced" tab of the engine.par file.

For EDI 5.2.0 and above, there is a section in Chapter 3 of the "EDI User's Guide" called "Tuning for Improved Performance" which contains more information on BC memory and job tuning for the EDI protocol.

Issue/Introduction

Preventing java.lang.outOfMemory conditions in BusinessConnect