WLI Performance Tips and Application Recovery

The following sections provides tips about designing and tuning high-performance Oracle WebLogic Integration applications. It contains the following topics:

Design-Time Performance Tips

Processes, Controls, and Callback Methods

Stateless processes are significantly faster than stateful processes.
Process controls are faster than service controls.
You get approximately the same performance when starting a process using the process control or message broker, but it is significantly faster to receive a process control callback than a message broker subscription. The message broker subscription filter mechanism uses a database to map the filter values to process instances. Process control callbacks are routed directly to the process instances.

Best Performance From Parallel Nodes in Business Processes

By default, the branches of a parallel node are transactionally isolated. To improve performance, you can override this behavior by setting the continueTransaction property in the source for each parallel element as follows:

Pending Messages in JMS Queues

Timer messages (messages set with a delivery time in the future) show up as “pending messages” in the Oracle WebLogic Server console.

Removing Pending JMS Timer Messages

For stateful processes, turn off maximum conversation lifetime if you are not using it:

For more information on the conversation lifetime feature, see “@jws:conversation-lifetime Annotation” in Java Web Service Annotations in Oracle WebLogic Web Services Reference.

Increasing the Transaction Timeout Period

The default timeout period for a transaction is 300 seconds (5 minutes). You can increase the amount of elapsed time before a transaction times out by using one of the following approaches:

Increase the value of the transaction-timeout element of wlw-config.xml. This will change the timeout period for all transactions in your application..
Increase the trans-timeout-seconds value for the AsyncDispatcher MDB in weblogic-ejb-jar.xml. This will change the timeout period for transactions processed by the AsyncDispatcher MDB only. For more information, see “trans-timeout-seconds” in “weblogic-ejb-jar.xml in WebLogic Server” in the weblogic-ejb-jar.xml Deployment Descriptor Reference in Programming Oracle WebLogic Enterprise JavaBeans.

Run-Time Tuning Tips

Using Flags to Start Oracle WebLogic Server and Maximize Performance

For optimum performance, use the following flags when starting Oracle WebLogic Server:

Tuning Oracle WebLogic Integration Applications

Oracle WebLogic Integration projects map onto J2EE resources. The primary EJB pools you can tune within a Oracle WebLogic Integration project are the project beans: the SyncDispatcher Stateless Session Bean (SLSB) pool and the AsyncDispatcher Message-Driven Bean (MDB) pool. These pools exist for every Oracle WebLogic Integration project in an application.

All synchronous requests are routed through the SyncDispatcher; all asynchronous (buffered) communication is routed through the AsyncDispatcher.

The preferred method to configure MDB pool size is to configure the EJBs in the project beans directory to use a dedicated thread pool by updating the weblogic-ejb-jar.xml file to contain a dispatch-policy element with the name of the thread pool to use.

For more information, see “dispatch-policy” in “weblogic-ejb-jar.xml Elements” in the weblogic-ejb-jar.xml Deployment Descriptor Reference in Programming Oracle WebLogic Enterprise JavaBeans.

You can use deployment plans to perform the same task. For more information, see Configuring Applications for Production Deployment in Deploying Applications to Oracle WebLogic Server.
Another method to configure MDB pool size is to set max-beans-in-free-pool for the project beans.

For more information about configuring MDB pool size, see “Setting Performance-Related weblogic-ejb-jar.xml Parameters” in Tuning Oracle WebLogic Server EJBs in Oracle WebLogic Server Performance and Tuning.

Configuring max-beans-in-free-pool for the JMS Event Generator

Yes. The JMS event generator by default has max-beans-in-free-pool set to 5. You can often set this value higher and improve performance.

For more information, see “Setting Performance-Related weblogic-ejb-jar.xml Parameters” in Tuning Oracle WebLogic Server EJBs in Oracle WebLogic Server Performance and Tuning.

Versioning for a Stateful Business Process

If you ever plan to use versioning with a long-running business process, version your process from the beginning before deploying your application in production mode. Otherwise, you must let non-versioned instances run to completion before deploying the new versioned process.

For more information, see “Managing Process Versions” in Process Configuration in Managing Oracle WebLogic Integration Solutions.

Setting Process Tracking Levels to Optimize Performance

Minimize process tracking levels as much as possible to optimize performance. Set tracking to none as the default, and track selected JPDs as needed.

For information on how to configure tracking levels, see “Managing Process Tracking Data” in “About Process Configuration” in Process Configuration in Managing Oracle WebLogic Integration Solutions.

Running the Archiver When Process Tracking Levels are set to None

Yes. You should run the archiver process during non-peak hours to clean the process monitor table for stateful processes.

For information on how to configure the archiver process, see “Managing Process Tracking Data” in Process Configuration in Managing Oracle WebLogic Integration Solutions.

Disabling Information Web Services Messages

Edit <domain-home>/apacheLog4jCfg.xml and change all occurrences of info to warn.

Using the Document Store With the Oracle WebLogic Integration Application

Each application will have a different threshold for the size of documents it is more efficient to pass by reference (using the document store) rather than inline. In general, the more trips a document makes, the better it is to use the document store. You configure the size of files passed by reference by setting the value of the weblogic.wli.DocumentMaxInlineSize parameter in the Oracle WebLogic Integration application domain's wli-config.properties file.

Choosing the Best Persistence Model for JMS

If you have a fast disk subsystem or a battery backed caching controller, file-based persistence can be quite a bit faster than JDBC.

Monitoring Parameters for Oracle WebLogic Integration Application Running Under Load

The following table shows parameters of key resources used by your Oracle WebLogic Integration application that you should monitor in the Oracle WebLogic Server Administration Console, and actions you should take if a problem condition arises.

Table 6-1 Parameters to Monitor in Oracle WebLogic Integration Applications
Parameter	Where to Monitor	Problem Condition	Actions Required
JDBC connection pool usage	ServicesJDBC Data Sourceseach data-sourceMonitoring.	Connections in use approaching maximum available.	Increase the `MaxCapacity` attribute of `JDBCConnectionPool`. For more information, see “How JDBC Connection Pools Enhance Performance” in Tuning Oracle WebLogic Server in Oracle WebLogic Server Performance and Tuning.
JMS async queues for project beans	ServicesMessagingJMS Modulesconversational-jms.	Many messages in the queue.	Increase the pool size for the AsyncDispatcher. For more information, see Tuning Oracle WebLogic Integration Applications.
`wli.internal.tracking.buffer`	ServicesMessagingJMS Modulesconversational-jms.	Many messages in the queue	Create a thread execute queue named `wli.internal. ProcessTracking`, and increase the number of threads in that pool. For more information, see Tuning Oracle WebLogic Server in Oracle WebLogic Server Performance and Tuning.
`wli.internal.instance.info.buffer`	ServicesMessagingJMS Modulesconversational-jms.	Many messages in the queue	Create a thread execute queue named `wli.internal. ProcessTracking`, and increase the number of threads in that pool. For more information, see Tuning Oracle WebLogic Server in Oracle WebLogic Server Performance and Tuning.

Reducing the Number of Transactions Timing out

If you have deployed your application as an exploded EAR, you can increase the amount of time that elapses before a transaction times out by increasing the value of trans-timeout-seconds in the Oracle WebLogic Server Administration Console. You should also change this value in the source for your Oracle WebLogic Integration application so that the value of trans-timeout-seconds is not reset to its default value when you redeploy the application.

If you have not deployed your application as an exploded EAR, trans-timeout-seconds is not accessible through the Oracle WebLogic Server Administration Console. You must increase the value of trans-timeout-seconds in your application, and then redeploy the application with the increased timeout value.

For information on how to change the value of trans-timeout-seconds, see “Edit Deployment Descriptors” in Implementing Enterprise Java Beans in Programming Oracle WebLogic Enterprise JavaBeans.

Causes for Memory Leaks in Application

Operating a Oracle WebLogic Integration application with the test console running. This is not actually a leak, but running with the test console on uses a lot of memory.

For more information, see Using Flags to Start Oracle WebLogic Server and Maximize Performance.

Lots of JMS timer messages. This is also not actually a memory leak, but this situation does cause an increasing amount of memory to be used. The memory is recovered when the messages are delivered.

To reduce JMS timer messages, see Increasing the Transaction Timeout Period.

WLI Application Recovery

The following section provides answers to questions about configuring Oracle WebLogic Integration applications for recovery. It contains the following topics:

Configuring Oracle WebLogic Integration Application for Recovery

You should check to make sure your Oracle WebLogic Integration application is configured in the following manner:

cgDataSource is configured in cgPool.Best Practices for Oracle WebLogic Integration Application Life Cycle
All JMS servers are targeted to a migratable target. (Migratable targets have the word migratable in the target name.)

Note:

If you need to change the targeting of one or more JMS servers in an active cluster, you must restart the cluster after you make changes to the targeting configuration.

The WLI Admin component of WLI System EJBs is targeted to the cluster. You can verify the targeting of WLI Admin by inspecting its configuration in the config.xml file for the WLI System EJBs application.

Note: WLI Admin can be targeted to the cluster only when JMS servers are targeted to migratable targets.

Retries and retry intervals are appropriate. Retries multiplied by retry interval should exceed the time it takes for JTA recovery to run.

If you need to tune your retries and retry intervals, you have the following choices:

Carefully set retry-count and retry-interval in your JPDs.
Set the retry-count and retry-interval of the async and error queues for each JPD project (WebApp).

Note:

This will break explicit retry settings on the JPD, but it is the easiest and recommended approach.

For more details, see JMSQueue in the Oracle WebLogic Server Configuration Reference.

JTA attribute TimeoutSeconds in the config.xml file is set to a value less than the value of the JDBCConnectionPool.XA TransactionTimeout attribute for XA connection pools.

For more information about TimeoutSeconds, see JTA in the Oracle WebLogic Server Configuration Reference.

JTA attribute MaxTransactions in the config.xml file is set to a value large enough to accommodate the number of simultaneous transactions that could occur on a server during recovery. For transaction intensive applications, you should increase the value of this attribute from the default setting.

For more information about MaxTransactions, see Domain-->Configuration-->JTA in the Oracle WebLogic Server Administration Console Online Help.

JDBCConnectionPool attribute MaxCapacity in the config.xml file is set to a value greater than the value of the execute queue ThreadCount attribute.

For more information about MaxCapacity, see JDBCConnectionPool in the Oracle WebLogic Server Configuration Reference.

For information about Server ThreadCount, see “Tuning the Default Execute Queue Threads” in Tuning Oracle WebLogic Server in Oracle WebLogic Server Performance and Tuning.

When using Oracle, the repository tables dba_2pc_pending, dba_2pc_neighbors, and dba_pending_transactions must have the right permissions for recovery to be called. If they do not, you will get a database error and recovery will fail.

Starting the Recovery Process

It can take several minutes for in-doubt transactions to show up in Oracle. There may be a race if recovery has started prior to Oracle detecting the loss of the TM. Wait several minutes before starting recovery—either by restarting the server or by doing a JTA migration.

The Recovery process will fail if after initiating recovery, you check the Oracle dba_2pc_pending table and see a record associated with the failed server that has a timestamp prior to initiating recovery. Restart the server.

Best Practices for WLI Application Life Cycle