Hi Ken, A purge should remove the messages that are currently pending on that physical consumer queue. Deleting the queue should remove the destination as well. Neither operation, by itself, explains why the same messages later appear again.
A Virtual Topic consumer is backed by a real queue, so I would separate two questions: 1. What recreated the queue? 2. What added the messages after it was recreated? The VirtualSelectorCacheBrokerPlugin can preserve selector knowledge while a consumer is offline, but it does not by itself republish old messages. Its presence would explain why a newly published Virtual Topic message can still be routed to an offline consumer queue; it would not be enough to explain old messages returning with no send activity. Before treating this as a KahaDB problem, I would capture the following immediately before purge, immediately after purge, and when the messages return: - broker name and startup time - exact physical queue name - QueueSize, EnqueueCount, DequeueCount, DispatchCount and InFlightCount - JMSMessageID values for a few affected messages - destination add/remove Advisory timestamps - NetworkConnector and duplex-bridge status - scheduled-message state - any VirtualSelectorCacheBrokerPlugin and virtualDestinationInterceptor configuration The Message IDs are especially useful. If the returned messages have new IDs, another send or fan-out path is active. If the same IDs return, investigate recovery, a network bridge, an outstanding transaction, or another broker/store instance before looking for a new producer. If this is a network of brokers, verify that the deployment is not forwarding both the Virtual Topic and its consumer queues. The ActiveMQ documentation warns that bridging both paths can produce duplicate fan-out. I would also reproduce the purge through the exact queue MBean rather than relying only on the web page, then watch whether EnqueueCount increases afterward. That distinguishes "the purge did not remove the entries" from "the queue was successfully emptied and later refilled." For KahaDB, MessageDatabase TRACE logging can show why journal files remain referenced. A retained journal file is not, by itself, evidence that its messages are currently pending. If this is still reproducible and you can take a consistent Store copy with the broker stopped, I maintain an open-source tool called MQ Watcher that may help inspect the journal evidence. I built it from similar ESB/message-broker support work; it is local/read-only and can correlate supported message, ACK/remove, subscription and transaction records. ActiveMQ 5.18.7 is one of the broker-fixture-tested versions. It does not determine root cause or reconstruct the broker's current queue state. https://github.com/kutaelee/mq-watcher Regards, Kutae Lee --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
