[
https://issues.apache.org/jira/browse/QPIDJMS-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435512#comment-17435512
]
ASF GitHub Bot commented on QPIDJMS-552:
----------------------------------------
franz1981 edited a comment on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953977356
> I do specifically want to avoid a default case where users need to end up
tweaking thread counts because an entirely legitimate blocking workload is
drowning out other stuff happening though. Seems like there are 2 different
routes for that to happen there (+based on seeing that happen elsewhere this is
done).
The default use case will remain the same as now ie one thread w its
executor service per session, but we can still give the option for users that
know that completions processing won't be blocking (or accept the trade-offs of
slow completion processing) and they would be handled by a shared thread pool
(configurable) that would auto-dispose when no JMS sessions requires it
anymore. This would just keep the number of completion threads under control
while fairly load balancing completion processing (FJ pool is pretty good at
work-stealing) ie a blocking processing won't stop other completions processing
until *all* completions threads are blocked.
--
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
