webMethods Adapter Runtime 10.7 | webMethods Adapter Runtime Documentation | webMethods Adapter Runtime User’s Documentation | Overview of the Adapter Runtime | Adapter Listeners and Listener Notifications | Single-Threaded and Multi-Threaded Listeners
 
Single-Threaded and Multi-Threaded Listeners
Beginning with Integration Server 9.5, Adapter Runtime based adapters support single-threaded listeners and multi-threaded listeners, based on the number of threads that a listener uses to process messages coming from the back end. Multi-threaded listeners improve performance by streamlining message processing.
With a single-threaded listener, the adapter processes incoming events from the back end one after the other in the order in which they arrive. The thread executes the most suitable notification for each event.
With a multi-threaded listener, the adapter uses a new thread for each event coming from the back end and processes the messages concurrently, which boosts performance. Therefore, if you have a long-running flow service for processing a message, subsequent messages do not have to wait for the first message to be processed.
Multi-threaded listeners rely on the Integration Server thread pool to concurrently read and process messages. When you enable a multi-threaded listener, for each incoming event from the back end an idle thread from the thread pool is allocated to execute the listener notification. When the maximum number of threads is reached, as specified in the Thread Count parameter when configuring a listener, new events have to wait and are processed only when threads become available.
With a multi-threaded listener, if the thread executing the notification uses a connection providing transaction support, the thread is responsible for committing or rolling back the transaction. In this case, each thread uses a separate connection.