About Multithreading in the JMS Receiver Component

The JMS Receiver is multithreaded and operates in batch mode. (In some previous versions, this component was single-threaded and ran in the background.)

A task for the JMS Receiver component starts automatically when the Siebel Server is started, where Default Tasks (alias DfltTasks) is set to 1. Otherwise, you must start tasks manually. For more information about DfltTasks, see Siebel System Administration Guide.

When a JMS Receiver task is started, a main task and several worker threads are created, whose number depends on the MinWorkQThreads and MaxWorkQThreads parameters listed in the following table.

After the worker threads are created, the main task thread starts calling the specified method on the EAI JMS Transport business service in an infinite loop, until a shutdown component is signaled. At the same time, the worker threads start their own infinite loop and perform the same duties as the main thread: they call the specified method on the EAI JMS Transport business service.

In effect, the ReceiveDispatchSend operation (or any method specified) is now called by multiple threads in the same task. Previously, a single sequential call to the ReceiveDispatchSend method was made in a single process. Now, the same operation happens in parallel. The thread parallelism effectively increases scalability while limiting CPU load and memory utilization.

Parameter	Description
MaxTasks	Total number of tasks that can run concurrently on a Siebel Application Object Manager. For more information about MaxTasks, see Siebel Performance Tuning Guide.
MaxMTServers	Maximum number of multithreaded processes that can run concurrently on a Siebel Application Object Manager. For more information about MaxMTServers, see Siebel Performance Tuning Guide.
MinMTServers	Minimum number of multithreaded processes that can run concurrently on a Siebel Application Object Manager. For more information about MinMTServers, see Siebel Performance Tuning Guide.
MaxWorkQThreads	Maximum number of child tasks/subtasks (worker threads) that start when a parent JMSReciever task is started. The default is 4. Note: This is the upper limit of JMSReceiver Tasks that can run concurrently. If there are n number of JMS Tasks already running no more JMS Tasks can be started unless n <= MaxWorkQThreads. N will be the total of all JMS Receiver Tasks running (parent and child worker threads). Note: MaxWorkQThreads and the Siebel Server’s MaxTask parameters both work together to limit the number of concurrent server Tasks. The smallest value from either parameter will be used. Example for how many concurrent JMS Receiver Tasks can run: MaxTasks = 20 and MaxWorkQThreads = 30. The number 20 will be used. MaxTasks = 20 and MaxWorkQThreads = 4. The number 4 will be used. If the two values are the same, it should be clear how many JMS Receiver Tasks can concurrently run.
MinWorkQThreads	Minimum number of child tasks/subtasks (worker threads) that start when a parent JMSReciever task is started. The default is 4.
MaxWorkQLength	Maximum number of work items handled by a worker thread. The default is 20. This parameter is not specific to JMS Receiver Tasks but applies, generally, to all Siebel Server Tasks. A single Task can have n number of worker Threads as designated by this parameter. When a new request is made, the Siebel Server decides if a particular Task can handle more work or if a new Task needs to be created to handle the request based on this parameter’s value.

Note: If the JMS Receiver load changes after the component has been started, and the parameter MaxWorkQThreads has been increased to handle the load, new JMS Receiver Tasks must be manually started in Siebel Server Manager. The new capacity will not automatically start new JMS Receiver Tasks.

Considerations When Using Multithreading

Multithreading works best when messages are atomic; that is, their processing does not depend on the processing of other messages. The messages can be processed in parallel without conflicts.

If one message is dependent on another, then the messages must be processed in the correct order. For example, you must create an account before creating a service request for it, and create an order before adding an order line item.

You can use validation scripting to make sure that parents are created before children. However, creating a data architecture that does not require additional scripting will deliver a performance benefit to the end-to-end solution.