[
https://issues.apache.org/jira/browse/QPID-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17374329#comment-17374329
]
Alex Rudyy edited comment on QPID-8534 at 7/4/21, 5:00 PM:
-----------------------------------------------------------
I do not think that this JIRA is correct.
The reason why connections {{#doWork}} is mainly invoked once is to keep
"fairness", especially when all IO threads are used. Though, that might result
in more frequent connection re-scheduling even for situations when there are
data to read or write, the current implementation guarantees some level of
fairness - each connection with "work" would have its chance to get invoked.
Otherwise, the connections with more work (big messages or more frequent IO
operations) would be dominating IO threads and blocking other connections with
smaller messages or less frequent IO operations.
Thus, the current implementation is by design.
I agree that implemented code is complex. I do not mind re-factoring to make it
simpler. However, it needs to be done with keeping existing behaviour including
fairness...
was (Author: alex.rufous):
I do not think that this JIRA is correct.
The reason why connections `#doWork` is mainly invoked once is to keep
"fairness", especially when all IO threads are used. Though, that might result
in more frequent connection re-scheduling even for situations when there are
data to read or write, the current implementation guarantees some level of
fairness - each connection with "work" would have its chance to get invoked.
Otherwise, the connections with more work (big messages or more frequent IO
operations) would be dominating IO threads and blocking other connections with
smaller messages or less frequent IO operations.
Thus, the current implementation is by design.
I agree that implemented code is complex. I do not mind re-factoring to make it
simpler. However, it needs to be done with keeping existing behaviour including
fairness...
> [Broker-J] Improper interruption of connection processing loop
> --------------------------------------------------------------
>
> Key: QPID-8534
> URL: https://issues.apache.org/jira/browse/QPID-8534
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Marek Laca
> Priority: Minor
> Labels: Broker, Connection, Java
>
> The network connection scheduler (NetworkConnectionScheduler class) contains
> a thread pool. IO-threads are polling jobs from the scheduler work queue and
> executing them. The connection job works in the loop. The loop is interrupted
> when there is not any data to process or all IO-threads are occupied.
> If the loop is interrupted then the IO-thread pushes the connection job back
> into the queue and picks the next job from the queue. It should ensure that
> any job is not abandoned and it is not waiting in the queue for ever.
> But when the number of jobs equals to the thread pool size then IO-thread
> stops processing the connection job, pushes it back into the queue and polls
> the same job again, again and again.
> The connection job could check whether is there any job in the scheduler
> queue. If the queue was not empty then the connection working loop would be
> interrupted and the thread could pick up another job. It would simplified the
> broker code significantly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
