[jira] [Commented] (ARTEMIS-1902) Message redistribution is not stopped when consumers count on remote node reaches 0 (AMQP)

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500239#comment-16500239 ] 

ASF subversion and git services commented on ARTEMIS-1902:
----------------------------------------------------------

Commit dde60b136a8ab2922bf9455abe6a78580ea0c442 in activemq-artemis's branch refs/heads/master from [~martyntaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=dde60b1 ]

ARTEMIS-1902 Ensure ServerConsumer close done once

Calling close multiple times on ServerConsumer can result in multiple
notifications being routed around the cluster.  This causes cluster
topology info to become skewed.  Which affects a number of components
such as message redistribution, metrics and can eventually cause OOM
should multiple queues be redistributing at the same time.


> Message redistribution is not stopped when consumers count on remote node reaches 0 (AMQP)
> ------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1902
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1902
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.6.0, 2.6.1
>            Reporter: Martyn Taylor
>            Assignee: Martyn Taylor
>            Priority: Critical
>
> With redistribution enabled and load balancing set to ON_DEMAND there is a case where a consumer count on a remote node reaches 0, however the local broker continues redistributing.  This can cause a whole magnitude of issues if the both brokers get in the same state.  Messages are redistributed back and forth between each other and never hit the local queue, resulting in message loss and potentially an OOM as each time the message is redistributed a copy is made.
> The issue looks to be caused by the cluster getting into a state where consumer counts are below 0.  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)