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.

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.