You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2021/11/02 09:20:00 UTC
[jira] [Commented] (QPIDJMS-552) JMS 2 Completion threads shouldn't
scale with the number of sessions
[ https://issues.apache.org/jira/browse/QPIDJMS-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437214#comment-17437214 ]
ASF GitHub Bot commented on QPIDJMS-552:
----------------------------------------
franz1981 commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-957253435
I've sent a change that it's introducing `HolderSuppliers` (bad name, so happy to receive feedbacks/suggestions) and `SharedDisposable` as a util that could be used on https://github.com/apache/qpid-jms/pull/45 to handle shared disposable/pre-configured resources.
Some points re this change:
1. thanks to FJ work stealing having a thread busy/blocked processing completions isn't a big deal as long as other FJ threads can handle other sessions completions
2. fairness isn't still "right": a perfectly fair system should just process a single completion and continue on the FJ pool, to guarantee other completions to get their chance to get executed; I've chosen to execute burst of completions to amortize the "virtual context switch" cost, improving locality, but in theory would be better to cap (time based) for how much time a burst of completions should keep a single thread busy (a good number could be the N * default timeslack_ns of linux ie N* 50 us)
It can now save creating a number of completion threads that is bounded to the number of sessions, just by adding `completionThreads=N` to the qpid url
This is one run of the [previous benchmarks](https://github.com/apache/qpid-jms/pull/44#issuecomment-951904530) with `completionThreads=2`, in violet, the FJ pool (single) thread in action, with 89 + 88 = 177 samples:
```
-> TEST 16,959 msg/sec
-> TEST 17,391 msg/sec
-> TEST 16,986 msg/sec
-> TEST 17,377 msg/sec
-> TEST 16,997 msg/sec
-> TEST 17,415 msg/sec
-> TEST 16,978 msg/sec
-> TEST 17,379 msg/sec
-> TEST 16,987 msg/sec
-> TEST 17,385 msg/sec
-> * 171,857 msg/sec
```
--
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-unsubscribe@qpid.apache.org
For queries about this service, please contact Infrastructure at:
users@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org