BPEL Threading model in SOA 11g

BPEL Threading model in SOA 11g

Reference: http://docs.oracle.com/cd/E21764_01/core.1111/e10108/bpel.htm#BABBGEFA

ThreadPool Name Property value
Invoke Thread Pool (for asynchronous invocations) or Dispatcher Invoke Thread dspInvokeThreads
min=1
default=20
Total number of threads allocated to process invocation dispatcher messages. Invocation dispatcher messages are generated for each payload received and are meant to instantiate a new instance. If the majority of requests processed by the engine are instance invocations (as opposed to instance callbacks), greater performance may be achieved by increasing the number of invocation threads. Higher thread counts may cause greater CPU utilization due to higher context switching costs.
Engine Thread Pool (i.e. for callback execution) or Dispatcher Thread Engine dspEngineThreads
min=1
default=30

 

Total number of threads allocated to process engine dispatcher messages. Engine dispatcher messages are generated whenever an activity must be processed asynchronously. If the majority of processes deployed are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, and wait activities), greater performance may be achieved by increasing the number of engine threads. Note that higher thread counts can cause greater CPU utilization due to higher context switching costs.
Dispatcher System Thread Pool dspSystemThreads
min=1
default=2
Total number of threads allocated to process system dispatcher messages. System dispatcher messages are general clean-up tasks that are typically processed quickly by the server (for example, releasing stateful message beans back to the pool). Typically, only a small number of threads are required to handle the number of system dispatch messages generated during run time.
Dispatcher Maximum Request Depth dspMaxRequestDepth
default=600
Sets the maximum number of in-memory activities to process within the same request. After processing an activity request, Oracle BPEL Process Manager attempts to process as many subsequent activities as possible without jeopardizing the validity of the request. Once the activity processing chain has reached this depth, the instance is dehydrated and the next activity is performed in a separate transaction. If the request depth is too large, the total request time can exceed the application server transaction time out limit.This process is applicable to durable processes.

BPEL Threading model usage for asynchronous BPEL process

oneWayDeliveryPolicy

Property Name Property value
bpel.config.oneWayDeliveryPolicy async.persist (Default)
Delivery messages are persisted in the database. With this setting, reliability is obtained with some performance impact on the database. In some cases, overall system performance can be impacted.
bpel.config.oneWayDeliveryPolicy async.cache
Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered. The system can become overloaded (messages become backlogged in the scheduled queue) and you may receive out-of-memory errors. If the rate at which one-way messages arrive is much higher than the rate at which they are delivered, or if the server fails, messages can be lost.
bpel.config.oneWayDeliveryPolicy sync
Direct invocation occurs on the same thread. The scheduling of messages in the invoke queue is bypassed, and the BPEL instance is invoked synchronously. In some cases this setting can improve database performance. Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance.

By default, incoming requests are saved in the delivery service database table dlv_message. These requests are later acquired by Oracle BPEL Server worker threads and delivered to the targeted BPEL process.
This property persists delivery messages and is applicable to durable processes. If the rate at which one-way messages arrive is much higher than the rate at which Oracle BPEL Server delivers them, or if the server fails, messages may be lost.

 

Advertisements

About Chenda Mok

19 years of hands on experience in software design and development with emphasis on Enterprise Application Integration (EAI), Services Oriented Architecture (SOA) and Identity Management (IDM) solutions. I’m a software engineer, member of the professional service delivery team working for Salesforce. Prior to this, I worked for Oracle as Solution Architect, through SeeBeyond(06/2005), then SUN’s acquisition (04/2009). After my master’s degree in computer science in 1997; I always delivered consulting on architecture, design, implementation on integration’s field. I’m interested in architecture using EAI/SOA/IDM/BPM/Cloud technologies, software development and Java’s related technologies. I may blog about my work/activities at Salesforce, but I do not speak for my employer, past, present or future.
This entry was posted in bpel, SOA Suite and tagged , , , . Bookmark the permalink.