Thanks for your reply Gary. >> When you get the WARN message, it is expected that the stats are wrong >> because the store should not be getting duplicates.
OS - Agreed. >> At the point that the store recognizes the duplicate, the stats and >> cursors may have >> already processed the message. >> The producerAudit should eliminate the duplicates at an earlier stage, >> so this needs to be enabled, and may need to be large to accommodate >> larger transactions. OS - How do I enable producerAudit? If I don't say "maxFailoverProducersToTrack=0" or "enableAudit=false", isn't it enabled by default? So in default AMQ configuration (as it ships), I am guessing producerAudit is enabled. Can you please elaborate on "need to be large to accommodate larger transactions" part? I think this is the magic that I am missing. Otherwise I just got the default configuration and added networkConnector to it. Even though I understand why duplicate messages are coming to the second broker (unacked messages replayed by the first broker), I just feel that I am missing something that will prevent duplicates eliminated before stats and cursors process them. Otherwise nobody could monitor queues properly, right? >> Can you build a simple junit tests case and attach it to one of the >> existing jiras or create your own. OS - Sure, I will give that I go. I am not a Java guy so might not be able to come back so soon. Thanks again, Ozan -- View this message in context: http://activemq.2283324.n4.nabble.com/Network-of-Brokers-Duplicate-message-add-attempt-rejected-tp3771301p3776983.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
