Thread pools

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.

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.

Only on-premise TotalAgility supports thread pools; TotalAgility running in on-premise multi-tenant or Azure environments does not support them.

How to: Add a thread pool