[
https://issues.apache.org/jira/browse/ARTEMIS-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16596165#comment-16596165
]
ASF GitHub Bot commented on ARTEMIS-2062:
-----------------------------------------
Github user gemmellr commented on the issue:
https://github.com/apache/activemq-artemis/pull/2277
Looks good to me, unsurprisingly. I just tweaked the commit message
slightly to fix/reverse part of the threshold statement in the first half.
Looking at it further, the same general thing can presumably still occur
for each message processed below the threshold until it is replenished but this
should avoid the worst of it, and altering that much would need a significant
change to those mechanics.
> AMQP: Reduce lock contention and allocations on message processing
> -------------------------------------------------------------------
>
> Key: ARTEMIS-2062
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2062
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: AMQP
> Affects Versions: 2.6.2
> Reporter: Timothy Bish
> Assignee: Timothy Bish
> Priority: Minor
> Fix For: 2.7.0
>
>
> On each inbound message the current AMQP handler attempts to top off credit
> for the receiver which results in a new runnable being created to hand off to
> the PagingManager or PagingStore and that code will result in a lock / unlock
> on the connection lock regardless of credit needing to be offered. The
> handler can tell if the credit is below the min credits threshold before ever
> needing to fire this action and can avoid that work for each message by only
> firing off the credit offering code when the credit is known to be low.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
