[
https://issues.apache.org/jira/browse/QPIDJMS-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435262#comment-17435262
]
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-953645864
> I dont believe it will ever work the way you want with a simple queue of
any size. You have to add hoops to manipulate it into behaving that way
A synchrnous queue (that's not a real queue, actually) works exactly like
that, but I've made a mistake about how completions are submitted...doc says
```
Direct handoffs. A good default choice for a work queue is a
SynchronousQueue
that hands off tasks to threads without otherwise holding them. Here, an
attempt
to queue a task will fail if no threads are immediately available to run it,
so a new thread will be constructed.
```
Let me think about it a bit more and I see if this PR can be closed or just
need to be refined to achieve the expected behaviour
>but I've made a mistake about how completions are submitted
It means that if the Netty event loop the connection belong is going to
submit completions for 2 different sessions (eg let's say 1 and 2) and session
1 is already processing completions:
- incoming completions vs session 1 should add them to the session
completion queue without bothering the thread pool, because there's already a
running completion thread handling them
- new session 2 completions won't find any completion thread awake and would
submit the request to the thread pool
- the synchronous queue is built to reject any offer if there is no thread
idle/awaiting on `take`, that means that the thread pool create a new one to
handle session 2 completions or reuse any existing one (without rejecting the
task offer)
It means that under heavy load completions can land so fast that we still
have 2 separate threads handling the 2 sessions completion, that's not exactly
what I want
--
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
