Uploaded image for project: 'ActiveMQ Artemis'
  1. ActiveMQ Artemis
  2. ARTEMIS-2264

PurgeOnNoConsumers prevent removal of messages with replication

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.7.0
    • Component/s: Broker
    • Labels:
      None

      Description

      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:

      1. Set up two brokers using the configuration from examples/features/ha/replicated-failback.
        Add an address like this to both brokers:
      <address name="purge">
          <multicast>
              <queue name="purge" purge-on-no-consumers="false"/>
          </multicast>
      </address>
      1. Start with purge-on-no-consumers=false
      2. Start master
      3. Start slave
      4. send 100 messages to topic "purge" using qpid JMS client
      5. Stop master
      6. Stop slave
      7. Set purge on-on-consumers=true
      8. Start master
      9. Start slave
        In console on master, note that "purge" has 100 messages, as expected at this point
      10. In console on master, use removeAllMessages() on destination
        Note that console shows zero messages on the destination
      11. Without attaching any clients, ctrl+c the master
      12. Slave starts as live
        In console on slave (which is now live) note that the destination has 100 messages
      13. 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".

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                nigro.fra@gmail.com Francesco Nigro
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 1.5h
                  1.5h