[
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 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.
> 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
