[
https://issues.apache.org/jira/browse/QPIDJMS-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434891#comment-17434891
]
ASF GitHub Bot commented on QPIDJMS-552:
----------------------------------------
gemmellr commented on pull request #44:
URL: https://github.com/apache/qpid-jms/pull/44#issuecomment-953007869
So, one 'slight' problem with this hehe. It doesnt do at all what is
described or I think both of us initially thought it would be doing. Digging
into the executor behaviour, rather than it potentially being elastic up to n
threads its instead binary where it has either 0 or 1 thread.
It only looks to create new threads if there are none, or if it is under the
max number when it cant insert into the task queue, which it always can and so
it only creates a first thread and then always uses that after (ignoring idle
timeout). Essentially the current impl serializes all completions for all
sessions on the connection onto 1 thread, and would halt completions across all
sessions if the thread were ever used to do any kind of longer lasting /
blocking work during any given completion callback, which is entirely allowed
and so that isnt acceptable.
A search confirms this as expected executor behaviour. To have it behave
otherwise you have to do stuff like play around with things like pretending the
task queue queue is full, extending the rejected execution handler, or having
it create core threads but allowing core threads to also timeout as well.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
> 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: [email protected]
For additional commands, e-mail: [email protected]
