Configuring thread pools

B2B Advanced Communications uses thread pools to manage concurrent tasks. A thread pool is a group of pre-instantiated, idle threads that stand ready to receive work.

When many short tasks need to be done rather than a few long tasks, thread pool usage is preferred over instantiating new threads for each task. Using thread pools can prevent diminished system performance that is caused by creating many new threads. If you tune thread pool sizes, the server components can reuse threads. The reuse of threads eliminates the need to create new threads at run time to handle each new request, which can improve system performance.

B2B Advanced Communications provides you with default thread pools that you can edit. You can also create new thread pools. When you create or edit system resources, you select the thread pool that the resource uses for processing. Tuning for maximum concurrency ensures that each server accepts enough load to saturate its processors.

Higher concurrent processing means higher resource requirements (memory and number of threads) on the server. Therefore, maximum concurrency must be balanced with other tuning objectives, such as the handling of large objects, handling many users, and providing quick response times.

Thread pool size directly impacts the ability of a server to run applications concurrently. For maximum concurrency, the size of the thread pool that is assigned to each resource must be set to an optimal value. However, adding more threads to a thread pool does not necessarily mean that the system can process more work. You can degrade performance by increasing the number of threads unnecessarily. A high default thread count uses more memory and can increase context switching (the storing and restoring the state of an in-process resource), which might degrade performance.

In general, if B2B Advanced Communications takes a long time to return calls to the database, you can assign more core (minimum number) threads to the thread pool. You can also increase the maximum number of available threads to improve performance. Or, if your database calls are short and involve rapid turnover, you can specify a smaller number of threads to improve performance.

Internal Comms Event Batching Threads is an out of the box, default thread pool, that B2B Advanced Communications provides for visibility event batching. The default thread pool is used to accumulate visibility events related to the exchanges. Based on the system property settings (COMMS_VISIBILITY_EVENT_BATCH_SIZE and COMMS_VISIBILITY_EVENT_BATCH_TIMEOUT), the visibility events are handed over to the worker threads for JMS posting, after which the visibility events are displayed on the user interface. If low performance is observed in visibility event publishing, the configuration of the default thread pool can be updated as required. You must not use the thread pool while configuring any resource such as, receivers, destinations, HTTP or HTTPS servers in B2B Advanced Communications.

Note: A user cannot delete or stop the Internal Comms Event Batching Threads thread pool.