The JMS XA/ASF Swiftlet uses the following thread pools:
This thread pool is shared from all JMS connections at the router side and used for outbound writes from router to JMS clients. These outbound writes are actually very short running tasks and a single thread of thread pool jms.connection can handle hundreds of connections. However, if there are slow network connections (e.g. dial up) or if large messages are being transfered, the thread blocks until the outbound write has been completed and other writes are stacked up and have to wait. The default setting for this pool is min-threads=5, max-threads=5. It ensures that there is always a free threads, even when the above conditions occurs. The max-threads attribute should be increased when all threads of this pool are continuously busy. This can be observed with SwiftMQ Explorer, Threadpool Swiftlet/Usage.
This thread pool is shared from all JMS session at the router side. In fact, all JMS work will be done from this pool. The work is scheduled as so-called async task that are dispatched into this pool. These tasks are actually short running so a thread from this pool will not block. The only exceptions are persistent operations, e.g. large messages stored via the JDBC Store Swiftlet. This can take time and a thread will block until the operation has been finished. The default setting for this pool is min-threads=5, max-threads=5. It ensures that there is always a free threads, even when the above conditions occurs. The max-threads attribute should be increased when all threads of this pool are continuously busy. This can be observed with SwiftMQ Explorer, Threadpool Swiftlet/Usage.