Thread pools (TP) automate activities (including sleep) by threads in
that pool. Each thread in a pool controls a separate automatic activity. Thread
pools can also be associated with synchronous maps.
TotalAgility
provides default thread pool for capture and non-capture automatic
activities.
The default thread pool contains 16 threads; this means that
TotalAgility
can execute 16 automatic activities at once. Additional activities queue
up on the thread pool queue (TPQ) and execute on a first-come, first-served
basis. You cannot modify the name or delete the default thread pools, however,
you can change their other settings, and also create multiple thread pools.
See
Add a thread pool.
Multiple thread pools offer the following advantages:
-
Lets you put long-running activities onto a separate thread pool.
This prevents long-running activities from delaying other short-running
activities. For example, with two thread pools, the short running activities on
thread pool 1 do not wait for completion of the long-running activities on
thread pool 2.
-
Control the number of concurrent calls, reduce the site size and
minimize potential performance delays. This is useful where an automatic
activity uses a third-party object method licensed for a limited number of
concurrent calls. For example, an email server may only be able to handle 10
concurrent calls at one time. You could set up a thread pool with 10 threads to
efficiently handle the processing of these automatic email activities.
Once thread pools are created, you can use these thread pools in a
process.
Important Only on-premise
TotalAgility
supports thread pools;
TotalAgility
in the Azure environment does not support them.