[
https://issues.apache.org/jira/browse/QPIDJMS-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435460#comment-17435460
]
ASF GitHub Bot commented on QPIDJMS-552:
----------------------------------------
franz1981 commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953921514
@gemmellr I'm going to send a separate commit that handle this same issue in
a different way, similar to what https://github.com/apache/qpid-jms/pull/45 has
done
ie completions are handled by a shared fork join pool (capable of work
stealing) that will be shutdown deterministically when no JmsSession(s) are
opened anymore (and reopened on demand).
Using a ForkJoin executor:
- enable work-stealing (and better load balancing)
- better handle contention while submitting from multiple threads
A different way to handle this should be to create a shared (reference
counted) event loop group and assign a different event loop executor in
round-robin to each session (that need completion processing), with some good
points:
- each session would have a single threaded executor (no need to have a
separate concurrent queue to handle completions)
- completion thread won't change during the session lifecycle
And an important drawback:
- no runtime load balancing: if an executor is shared by many busy sessions
(processing many completions), an unlucky session won't have any other Thread
helping to process its completions, despite the other event loops are idle
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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
