qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6794) [Java Broker] Reduce latency in IO by processing work immediately after select()
Date Fri, 13 Nov 2015 16:48:11 GMT

    [ 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: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message