[
https://issues.apache.org/jira/browse/ARTEMIS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-2264.
------------------------------------
Resolution: Fixed
Fix Version/s: 2.7.0
> 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
> Priority: Major
> Fix For: 2.7.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> 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:xml}
> <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 10 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)
