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
running in on-premise multi-tenant or Azure environments does not support them.