[
https://issues.apache.org/jira/browse/QPIDJMS-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro updated QPIDJMS-552:
------------------------------------
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.
was:
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 the same thread to handle their completion events.
This model should allow saving 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.
> JMS 2 Completion threads shouldn't scale with the number of sessions
> --------------------------------------------------------------------
>
> Key: QPIDJMS-552
> URL: https://issues.apache.org/jira/browse/QPIDJMS-552
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 1.3.0
> Reporter: Francesco Nigro
> Priority: Major
>
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
