Wednesday, October 28, 2009

Tuning BPEL and Weblogic 9.2

This article describes how to optimize Oracle BPEL process manager (10.1.3.4) running on Oracle WebLogic Server (9.2).

WebLogic Server

JDK Version

Use the latest SUN Java Virtual Machine. This can be downloaded from the SUN web site, currently JDK5 build 21 is available:

http://java.sun.com/javase/downloads/index_jdk5.jsp


Unpack this JVM into $WLS_HOME/wls and point the admin and managed servers to this new JDK;

$WLS_HOME/user_projects/domains/SOADomain/bin/setDomainEnv.sh

Oracle certification on JVM can be found here:

http://www.oracle.com/technology/software/products/ias/files/oracle_soa_certification_r3_10.1.3_matrix.xls


Memory settings
Configure the heap and memory size correctly. Do not increase the Java Heap size to large. This could lead into swapping or too much overhead in JVM. In general I suggest to set the -Xms and -Xmx equal and make these 1. Leave at least 30% memory for de rest; O/S, Apache...

Garbage collection is happening when the BPEL PM is overloaded with tasks. Full garbage collection will take place. A parameter that influences this behavior a bit, is to reduce the Java stack size. By default the stack size is 512KB. This is for each thread. If you have short running processes, they do not occupy a large stack. You can reduce the stack size. Use the value -Xss128k or even -Xss96k.

The permanent generation holds data needed by JVM to describe objects that do not have an
equivalence at the Java language level. Eg: objects describing classes and methods. Consider setting –XX:MaxPermSize equal to –XX:PermSize to minimize major collections.

If the servers contains multiple CPUs (cores) whe can use aggressive heap JVM flag. This option inspects the machine resources and attempts to set various parameters to be optimal for long-running, memory allocation-intensive jobs.

Summary; set the memory settings to:

-Xms1024m -Xmx1024m -XX: -Xss128k -XX:MaxPermSize=512m -XX:PermSize=512m -XX:+AggresiveHeap

Note; performance tests should be carried to find the optimal values. This is a best practice recommendation.

JTA timeouts
Be default the global transaction time-out period of WLS is set to 90 seconds. In a BPEL PM environment this is to low. Asynchronous processing can run longer before there state is dehydrated. Increase the global JTA time-out to 3600 seconds.

WLS Console -> SOADomain -> Configuration -> JTA

BPEL Process Manager

Dehydration store
In high throughput environments, locks can occur in the database that will hold up the BPEL PM from running. This can be improved by increasing the number actions in data block of the database:
  • alter table CUBE_INSTANCE initrans 16;
  • alter table CUBE_SCOPE initrans 16;
Threads
Per domain the threads can be set that are used for synchronous processing (InvokeThreads) and a-synchronous processing (EngineThreads). By default they are
  • dspInvokeThreads 20
  • dspEngineThreads 30
I would recommend setting these values to the default on all domains.

Note; performance tests should be carried to find the optimal values. This is a best practice recommendation.

Datasources
The connection pool size must be greater than or equal to the sum of the dspMaxThreads property value in Oracle BPEL Control. If you have configured multiple domains, add all dspMaxThreads property values and compare that value with the data source's max-connections value. The default max-connections on WLS is 15.

Maximum DB Connections >= For-Each-Domain(dspInvokeThreads + dspEngineThreads)

Increase the maximum value of the data sources:
  • jdbc/BPELServerDataSourceWorkflow
  • jdbc/BPELServerDataSource

Note: Check also the time-out parameters; Statement Timeout; Maximum Waiting for Connection; Inactive Connection Timeout

Time-out
By default a synchronous process can run for maximum 45 seconds. After this period BPEL PM will mark this instance as failed. Increase this parameter to a higher value. During load test we have seen that this value can be to lows.
Change this time out in the BPEL Admin console.

syncMaxWaitTime 120

BPEL Processes
Any process in the BPEL is dehydrated to the database. There are processes, such as monitoring; auditing or processes that execute simple tasks that are not needed to be dehydrated. This can be achieved by disable dehydration and only dehydrate in case of a failure.
Put in those BPEL process, in their BPEL.XML file the following options:

<configurations>
<property name="inMemoryOptimization">true</property>
<property name="completionPersistPolicy">faulted</property>
<property name="completionPersistLevel">All</property>
</configurations>

Adapters
Make sure that all adapters, database and JMS configuration are using JNDI entries that point to data sources or JMS factories/modules. It is not allowed that they have local connection definitions.

In a cluster environment, you expect that adapters doing the same work on two different nodes might encounter a race condition. So you would like to configure a singleton adapter. This note describes how to do it.

In BPEL.XML file of the polling process:

<activationagents>
<activationAgent className="oracle.tip.adapter.fw.agent.jca.JCAActivationAgent"
partnerLink="JMSRead">
<property name="portType">Consume_Message_ptt</property>
<property name="clusterGroupId">adapterCluster</property>
<property name="clusterAcrossSubnet">false</property>
</activationagent>
</activationagents>

Logging
Reduce the log level in the BPEL console. Most of the logging is set to 'ALL' in this case the default domain, while the Poland domain has the default configuration.

Reducing the logging results in smaller readable log files. If you put everything on ALL, as it is now, you get too much information and some information is only needed for Oracle Support. It is recommended to:


Put everything to INFO

Then set:
default.collaxa.cube.activation DEBUG
default.collaxa.cube.engine.delivery DEBUG
default.collaxa.cube.engine.deployment DEBUG
default.collaxa.cube.services DEBUG
default.collaxa.cube.ws DEBUG
default.collaxa.cube.xml DEBUG

Changes can be applied without restarting the server.

Note: In production environment set the log level to Info and set the audit level to production.

References:

http://download.oracle.com/docs/cd/B31017_01/core.1013/b28942/tuning_bpel.htm
http://orasoa.blogspot.com/2007/01/tuning-bpel-in-nutshell.html
http://download.oracle.com/technology/tech/soa/soa_best_practices_1013x_drop3.pdf
http://puchaanirudh.blogspot.com/2009/01/jvm-tuning-for-soa-suite-applications.html
http://blogs.sun.com/jonthecollector/entry/presenting_the_permanent_generation
http://forums.oracle.com/forums/thread.jspa?messageID=3344909&#3344909
http://forums.oracle.com/forums/thread.jspa?threadID=962571
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Friday, October 23, 2009

Learing Oracle SOA 11g

As I execute SOA 11g training for customers and colleagues in SOA 11g. There is always need to learn Oracle SOA 11g on your own. There are people who just do it, download, install en run. People who read the Oracle documentation and people who are reading external books. On these books is:

Due to my blog, the publisher send me a copy to review this book to find my opinion.

I am always sceptic about books. Apart of the content the book must be handsome, having a good index and printed on nice paper.

I have read the book, I a must say the book is good when you want to start with Oracle SOA 11g and you have experience with SOA, but also when you just want to start with SOA 11g technology.

The book gives you a breadth overview on the SOA 11g components;
  • Service Component Architecture
  • Installation
  • Mediator
  • BPEL
  • Event Driven Network
  • Human Tasks
  • Service Bus
  • Security
  • Adapters
  • Business Activity Monitor
  • Service Data Objects
  • Business-2-Business
Experienced people will read this book very quickly and learn it efficiently. Less experienced people use this book as a guide through the new Oracle SOA 11g technology.

The book contains a lot screen-shots and clear examples. These examples can be download from here. Another nice SOA 11g example application and docs, click here.

One disadvantage... I miss the upgrade chapter. How to migrate from SOA 10g to SOA 11g, but that is described here.

Wednesday, October 07, 2009

FMW SOA 11g and DHCP

During my trainings sessions forFMW SOA 11g, some of the attendees had issues with deploying and / or testing composites. They all had installed FMW SOA 11g on there laptop and used Microsoft Windows XP. We solved this issue by forcing FMW SOA 11g to be listening to localhost.

By default installation of FMW SOA 11g, the weblogic server is listen to any netwrok card (WIreless, Cabled, VMWare, loopback etc...).

To force SOA 11G to listen to local host apply the following settings.

Change in your config.xml file, from the WLS Domain directory, that the Admin server and soa_server the listen adress to localhost (user_projects/domains/soa_domain/config):
      <server>
<name>AdminServer</name>
<listen-address></listen-address>
</server>
<server>
<name>bam_server1</name>
<ssl>
<name>bam_server1</name>
<listen-port>9002</listen-port>
</ssl>
<machine>LocalMachine</machine>
<listen-port>9001</listen-port>
<listen-address></listen-address>
</server>
<server>
<name>soa_server1</name>
<ssl>
<name>soa_server1</name>
<listen-port>8002</listen-port>
</ssl>
<machine>LocalMachine</machine>
<listen-port>8001</listen-port>
<listen-address></listen-address>
</server>

Into:

<server>
<name>AdminServer</name>
<listen-address>localhost</listen-address>
</server>
<server>
<name>AdminServer</name>
<listen-address>localhost</listen-address>
</server>
<server>
<name>bam_server1</name>
<ssl>
<name>bam_server1</name>
<listen-port>9002</listen-port>
</ssl>
<machine>LocalMachine</machine>
<listen-port>9001</listen-port>
<listen-address>localhost</listen-address>
</server>
<server>
<name>soa_server1</name>
<ssl>
<name>soa_server1</name>
<listen-port>8002</listen-port>
</ssl>
<machine>LocalMachine</machine>
<listen-port>8001</listen-port>
<listen-address>localhost</listen-address>
</server>

Replace your local hostname in (user_projects/domains/soa_domain/config):

echo "$1 managedserver1 http://*vijfhuizen*:7001"
...
ADMIN_URL="http://vijfhuizen:7001"

Into
echo "$1 managedserver1 http://*localhost*:7001"
...
ADMIN_URL="http://localhost:7001"

Set the SCA CallbackURLK and serverURL! This is done in the file:

YOUR_SOA_DOMAIN/config/soa-infra/configuration/soa-infra-config.xml
...
<datasourceJndi>jdbc/SOALocalTxDataSource</datasourceJndi>
<txDatasourceJndi>jdbc/SOADataSource</txDatasourceJndi>
<serverURL>http://localhost:8001</serverURL>
<callbackServerURL>http://localhost:8001</callbackServerURL>
<cache-config>
...
Restart the SOA Application Server.