Copyright © Cloud Software Group, Inc. All Rights Reserved

Controlling Execution of TIBCO ActiveMatrix BusinessWorks Services

Process starters create process instances to handle incoming events. Process instances consume memory and CPU resources on your system. Depending on the available machine resources, you may only be able to run a limited number of process instances concurrently.

Process instances typically remain in memory as long as they are executing an activity. If the process instance is waiting for an incoming event (for example, a Wait for Adapter Message activity), the process instance can be paged out to disk and resumed later after the event arrives. New process instances are paged out to disk until there is available memory and resources to accommodate them.

You can use TIBCO Administrator to control the execution of TIBCO ActiveMatrix BusinessWorks process instances. This is useful if your system has limited memory or resources, or if you want to restrict process instances to run sequentially.

The TIBCO ActiveMatrix BusinessWorks Process Configurations dialog allows you to specify the following:

•	Max Jobs — Specifies the maximum number of process instances that can concurrently be loaded into memory.

•	Use Activation Limit — Specifies that once a process instance is loaded, it must remain in memory until it completes.

•	Flow Limit — Specifies the maximum number of currently running process instance to start before suspending the process starter.

To change process configuration properties, perform the following procedure:

1.	In TIBCO Administrator, click Application Management.

2.	Select an application and expand it.

3.	Click Configuration.

4.	In the Configuration Builder pane, click a process name. A process is named with a .par suffix.

5.	Click the Advanced tab.

6.	Change properties as required. The remaining topics in this section provide information about the properties you can set.

7.	Click Save.

Specifying the Maximum Number of Concurrently Active Processes

Incoming events may not be evenly distributed over time. That is, there may be periods where a large number of incoming events occur and other periods where relatively few events occur. To prevent your system from being overwhelmed by incoming events, the Flow Limit field limits the number of process instances created by a process starter. This allows you to control the flow of processing so that incoming events are no longer accepted when the limit is reached.

Controlling the flow of processing is especially useful when you are using protocols that can store unsent messages on the server until the receiver is ready to process them. For example, if your process definition polls an email server for new messages (that is, Receive Mail is the process starter), and then you can set Flow Limit to control the number of process instances created for each new email. Email that has not been processed remains on the email server until the process engine is ready to create more process instances. Other protocols where this approach are useful are TIBCO Rendezvous Certified Messaging (RVCM), JMS durable topic subscriptions, and JMS queues.

When a process engine reaches the specified Flow Limit, it is placed in a FLOW_CONTROLLED state. In this state, the process engine can continue executing existing process instances, but new process instances are not allowed. Incoming messages can then be directed to another process engine. A process engine will resume creating new process instances once a sufficient number of its current process instances have completed. Typically a process engine comes out of the FLOW_CONTROLLED state when the number of process instances completed is approximately half of the value specified for the Flow Limit property.

 

The HTTP Receiver process starter uses a different mechanism for controlling the flow of incoming requests. When Flow Limit is set on a process definition containing this process starter, the maximum number of incoming requests is limited to <flowLimitValue> -1. It is recommended that you use the minProcessors and maxProcessors properties to control the flow of incoming HTTP requests instead of using the Flow Limit property. See the description of the HTTP Connection resource in TIBCO ActiveMatrix BusinessWorks Palette Reference for more information on flow control of the HTTP Receiver process starter.

The Max Jobs field in the Process Configurations dialog allows you to specify the maximum number of concurrent process instances that can be stored in memory. For example, if you set Max Jobs to 5, the process engine can only keep five process instances in memory. Any process instances created once the maximum is reached must be paged out to disk.

Specifying a value for Max Jobs causes the process engine to incur some overhead for managing the paging of process instances to and from disk. If you have sufficient system resources and do not expect incoming events to exceed the limits of your system, consider specifying Max Jobs as 0. This allows the process engine to create an unbounded number of process instances and eliminates the overhead of paging.

Keeping Services in Memory

The Use Activation Limit field specifies that once a process instance is loaded into memory, it should not be paged out to disk until it completes. This option is useful if you wish to specify sequential processing of incoming events, or if you want to enforce limited concurrent execution of process instances.

Effects of Setting the Configuration Fields

The Max Jobs and Use Activation Limit options work together to provide different concurrency limits. The Flow Limit field also affects the concurrency limit. The next table describes the effects of various combinations of these options.

Table 2 Effects of various configuration settings

Max Jobs	Use Activation Limit	Flow Limit	Description
0	Cleared or selected	0	An unlimited number of process instances can be created and concurrently loaded into memory. Use Activation Limit is ignored when Max Jobs is set to 0.
0	Cleared or selected	N	No paging of process instances. Allows up to N process instances before placing process starter in flow controlled stated. Use Activation Limit is ignored when Max Jobs is set to 0.
1	Selected	N	One process instance is loaded into memory at a time and kept there until it completes its execution. This guarantees incoming events are processed in the order in which they occur. Up to N process instances are paged to disk, and then the process starter is placed into flow controlled state. Note: If your goal is to sequentially process incoming events, use the Sequencing Key field on the Misc tab of the process starter. Using Max Jobs and Use Activation Limit incurs overhead as process instances are paged to disk and retrieved from disk.
1	Selected	0	Once process instance is loaded into memory at a time and kept there until it completes its execution. This guarantees incoming events are processed in the order in which they occur. There is no limit on the number of process instances that can be created and paged to disk. Note: If your goal is to sequentially process incoming events, use the Sequencing Key field on the Misc tab of the process starter. Using Max Jobs and Use Activation Limit incurs overhead as process instances are paged to disk and retrieved from disk.
1	Cleared	N	One process instance is loaded into memory at a time, but up to N process instances are created. Incoming events can be processed in any order because process instances are not kept in memory until they complete execution.
M	Selected	0	An unlimited number of process instances can be created, but only M are loaded into memory and processed concurrently. This setting ensures a limited amount of concurrent processing. This situation is useful if you have limited resources, such as database connections. You can set Max Jobs to a relatively small number and the Use Activation Limit option keeps each service in memory until the service completes. Each loaded process uses a machine resource until the service completes. Once a service releases the resource, a new process can be loaded into memory and the corresponding service can use the resource.
		N	Same as above, except only N process instances are created before the process engine is placed in the flow controlled state.
M	Cleared	0	An unlimited number of process instances can be created, but only M are loaded into memory and processed concurrently. After M process instances are created, new process instances are paged to disk. There is no guarantee of the order in which process instances are executed.
		N	Same as above, except only N process instances are created before the process engine is placed in the flow controlled state.

Copyright © Cloud Software Group, Inc. All Rights Reserved