[jira] [Created] (ARTEMIS-2264) PurgeOnNoConsumers prevent removal of messages with replication

["Francesco Nigro (JIRA)" <ji...@apache.org>]

Francesco Nigro created ARTEMIS-2264:
----------------------------------------

             Summary: PurgeOnNoConsumers prevent removal of messages with replication
                 Key: ARTEMIS-2264
                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2264
             Project: ActiveMQ Artemis
          Issue Type: Bug
          Components: Broker
            Reporter: Francesco Nigro


In a master-slave, shared-nothing broker pair, Messages that have been purged administratively using the JMX removeAllMessages() API can apparently be restored after a fail-over and fail-back. In fact, what is happening is that the purge is not taking effect on the broker in the backup role, so the pre-purge message store ends up on the master after the fail-back.

The following sequence of steps reproduce the problem:
 # Set up two brokers using the configuration from examples/features/ha/replicated-failback. 
Add an address like this to both brokers:


{code:java}
<address name="purge">
    <multicast>
        <queue name="purge" purge-on-no-consumers="false"/>
    </multicast>
</address>{code}

 # Start with purge-on-no-consumers=false
 # Start master
 # Start slave
 # send 100 messages to topic "purge" using qpid JMS client
 # Stop master
 # Stop slave
 # Set purge on-on-consumers=true
 # Start master
 # Start slave
In console on master, note that "purge" has 100 messages, as expected at this point
 # In console on master, use removeAllMessages() on destination
Note that console shows zero messages on the destination
 # Without attaching any clients, ctrl+c the master
 # Slave starts as live
In console on slave (which is now live) note that the destination has 100 messages
 # Start master
Master takes over live role, slave now backup
In console on master (which is now live) note that the destination has 100 messages

It seems that the removeAllMessages() method in step 11 did not cause the broker "slave", which was a backup at that time, to receive an updated message store from "master".



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