[
https://issues.apache.org/jira/browse/QPID-6794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15004266#comment-15004266
]
Keith Wall commented on QPID-6794:
----------------------------------
On r1713921, when SelectionTask#performSelect goes into 'eat what you kill'
mode, won't it be double accounting? performSelect will have incremented the
running count already and processConnection will do it too. Won't this mean
that processConnection will be premature in determining that the pool is full?
If SelectorThread#run took sole responsibility for incrementing/decrementing
running count, I think the problem would be solved.
> [Java Broker] Reduce latency in IO by processing work immediately after
> select()
> --------------------------------------------------------------------------------
>
> Key: QPID-6794
> URL: https://issues.apache.org/jira/browse/QPID-6794
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Fix For: qpid-java-6.0
>
>
> Rather than having a dedicated SelectorThread which passes work to a thread
> pool, instead perform the select in the thread pool, continue immediately
> processing the results in the same thread, and dispatch the select task to be
> executed again in the thread pool.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
