An explanation how threads are used in SwiftMQ can be found
here. Because of the async task based design there should be no thread of a pool go into a blocking state. The only reason why a thread could take longer to finish is during persistent operation against a JDBC store or on a outbound network write (pool jms.connection) on a slow network link (modem etc).
However, if you have many clients producing & consuming many messages, the number of task in the jms.session pool is high and increasing the number of threads may increase throughput. But more threads will also add more thread context switching. To verify whether jms.session needs more threads simply use SwiftMQ Explorer and check Threadpool Swiftlet / Usage. If the running thread count of jms.session is constantly at maximum, increase maximum threads.
Concurrent queue consumer will be best served by
Local Clustering. This can double your throughput compared to multiple queue consumers.
