Impact of jms thread count increase

[q-alot]

We have 16 processes consuming from 2 queues, 8 processes are connected to Q1 and 8 to Q2.
Once messages are read from the queues by a java application, they are sent to 2 different servers (S1 and S2).

My question is related to the number of jms.session threads (or any other parameter). Counting that the default value is 10, does that mean that there are 10 threads to serve 16 processes?

If for some reason S1 goes down or responds very slowly, 8 threads are going to be locking up messages in Q1, but more important than that only 2 threads (10 total threads - 8 locked) are going to be available to attend 6 appication.

My conclusion was that we should have as many jms.session threads as consumers connected to one router to avoid deadlocks or throughput problems afffecting S2 when the problem is that S1 is not available. Is this correct?

What is the potential impact of increasing the thread count to 20 for example? Any risk? Any recommended max value for this case?

What is the impact / role of network.session parameter?
Please let me know if you need more details to answer this question.

Thanks

Q-alot

[IIT Software]

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.