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.
For more information about flow control of the HTTP Receiver process starter, see the description of the HTTP Connection resource in TIBCO ActiveMatrix BusinessWorks™ Palette Reference.
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.