You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@activemq.apache.org by tabish121 <gi...@git.apache.org> on 2018/08/28 20:12:32 UTC

[GitHub] activemq-artemis pull request #2277: ARTEMIS-2062 Only attempt to refill cre...

GitHub user tabish121 opened a pull request:

    https://github.com/apache/activemq-artemis/pull/2277

    ARTEMIS-2062 Only attempt to refill credit when needed

    Avoid firing the offerProducerCredit code when we know that the credit
    is low enough that a refill is needed which avoids lock contention and
    garbage creation as each inbound message is processed.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/tabish121/activemq-artemis ARTEMIS-2062

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/activemq-artemis/pull/2277.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #2277
    
----
commit 04657c323f2f3235320aa5b14130acb07fc13c01
Author: Timothy Bish <ta...@...>
Date:   2018-08-28T20:11:14Z

    ARTEMIS-2062 Only attempt to refill credit when needed
    
    Avoid firing the offerProducerCredit code when we know that the credit
    is low enough that a refill is needed which avoids lock contention and
    garbage creation as each inbound message is processed.

----


---

[GitHub] activemq-artemis pull request #2277: ARTEMIS-2062 Only attempt to refill cre...

Posted by asfgit <gi...@git.apache.org>.

Github user asfgit closed the pull request at:

    https://github.com/apache/activemq-artemis/pull/2277


---

[GitHub] activemq-artemis issue #2277: ARTEMIS-2062 Only attempt to refill credit whe...

Posted by gemmellr <gi...@git.apache.org>.

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.


---