[QPIDJMS-552] JMS 2 Completion threads shouldn't scale with the number of sessions

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.3.0
• Component/s: qpid-jms-client
• Assignee: Unassigned
• Reporter: Francesco Nigro
• Created: 26/Oct/21 15:13
• Updated: 01/Mar/22 13:20

Description

JMS 2 Completion threads are now tied to be one per JMS Session ie a client application with N JMS sessions need N completion threads to handle the completion events.

Given that the asynchronous model of JMS 2 allows users to have few threads handling many JMS sessions, should be better to reduce the amount of completion threads without exceeding the number of available cores and shrink/grow according to the completion event processing load.

If the user confine a connection in a thread handling many JMS sessions and the completion events are issued by the same Netty thread in sequence, if the completion processing for a JMS Session is fast enough, next JMS Sessions can reuse existing completion threads instead of using a new one.
This model save using too many completion threads for users tasks that are supposed to be very fast: if the user task cause a specific JMS Session completion thread to block, the expectation is that the system should be able to create a new completion thread to handle other JMS Session completion events, as expected.