that is a problem, if broker death occurs between the first send to a composite destination and the last send (all of which occur on the broker), the resend will be suppressed but there is no guarantee that each of the composite dests got the message.
The duplicate suppression is not aware of composite destinations. It should be possible to disable the duplicate suppression on the persistence adapter using <kahaDB maxFailoverProducersToTrack="0" /> Also, I think a send transaction would help, it should encompass all of the composite destinations. On 13 July 2011 09:38, oseymen <ozan.sey...@tdpg.com> wrote: > Thanks Gary. > > I've tested below with Fuse 5.5 (apache-activemq-5.5.0-fuse-00-27) and > unfortunately the issue is there. However what it boils down to is this > "suppressing duplicate message send" message in composite destinations. > > In order to prove this is the case, I started eliminating components one by > one. I removed network-of-brokers from my setup. I took the vanilla > (default) activemq.xml from the distribution and setup a virtual topic with > 3 queues. I started sending 3000 messages with my producer which simply > sends messages in auto-acknowledge mode using failover transport. While > producer is running, I killed and restarted activemq multiple times > (killed: prematurely. Just close the console window in which AMQ was > running). > > I am seeing 3000 in one queue and less messages (~2998) on other queues. In > the log file I have DEBUG statements saying "suppressing duplicate message > send...". So after AMQ restart, AMQ is suppressing the message to other > queues thinking that it is duplicate by looking at the last stored sequence > id. In this case last stored sequence id is correct but this stops message > propagation to other queues in composite destination setup. > > I searched this in Google and spotted Gary's comment on > https://issues.apache.org/jira/browse/AMQ-2800. Gary says "duplicate message > sends can occur with the non transactional use of the failover: transport. > It can happen if a send is in progress when a failover reconnection occurs > back to the same broker (as if there was a temp network partition) and the > send reply is not received. A non transactional client will resend the > message which needs to be suppressed by the audit". He also recommends > disabling audit. However this is for JDBCMessageStore as far as I understand > and not for KahaDB. > > I am sure that this is the reason for my problems as well. I really couldn't > understand how to disable audit for KahaDB but looking at the configuration > schema, I applied following changes to the config but none of them fixed the > problem: > 1. enableAudit="false" to PolicyEntry for all topics and queues. > 2. maxProducersToAudit="0" to PolicyEntry for all topics and queues. > > Does anyone have any ideas on how to fix this? If not, I will raise a JIRA. > > Thanks, > Ozan > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Message-loss-in-network-of-brokers-transactional-send-tp3588714p3664510.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- http://fusesource.com http://blog.garytully.com
