If you have a network of brokers, messages on topics will be forwarded to whichever broker the consumer connects to, without duplicate delivery of any messages so long as no messages were processed by the consumer without being ack'ed. If you were using queues, there's the potential for messages to get stranded on a broker if no consumers are left, but this isn't possible for topics. (I'm not clear on the reason that topics can't get messages stranded even when consumers bounce between brokers, and unfortunately http://activemq.apache.org/networks-of-brokers.html doesn't describe why that is.)
So I think that ActiveMQ's base capabilities will do exactly what you want, and if you're seeing redelivery of messages that were successfully acked when the consumer bounces to another broker, I think that would indicate a bug in ActiveMQ rather than a missing feature. On Sun, Oct 19, 2014 at 6:05 PM, Noel OConnor <noel.ocon...@gmail.com> wrote: > Take a look at idempotent consumers in camel. This may help you out as a > basis for your plugin if you decide to go with it. > On Oct 18, 2014 5:47 PM, "Andreas Gies" <andr...@wayofquality.de> wrote: > > > Hi > > > > I am using ActiveMQ 5.10 in an application. So far the requirement for > the > > remote locations has been for pure store and forward capabilities, > > so that a single AMQ broker was sufficient. This has changed in a way > that > > now 2 nodes should be present in the remote location for > > resilience and load balancing. I had considered a master/configuration as > > the requirement for resilience is stronger than that for load balancing. > > > > However, the situation in those locations is that I don’t have a shared > db > > nor a shared filesystem. As far as I have understood the replicated > level db > > would require at least 3 nodes ? > > > > This is why I have chosen a network of brokers in the end, which works > > well for any Queue based communication. > > > > Now my problem is that there is one client application that is provided > by > > a 3rd party and uses durable subscriptions. It would be quite an effort > > to change that application towards using queues, so that I could consider > > virtual destinations. > > > > The problem occurs two-fold: > > > > Assume a Subscriber connects to BrokerA, then disconnects and reconnects > > to Broker B. It consumes messages for a while, than disconnects > > and reconnects to Broker A. All messages that have already been consumed > > while it was connected to Broker B will be delivered again. > > > > My question is now whether this could be avoided by means of ActiveMQ > > alone ? - I was contemplating a broker plugin to track messages that > > have been consumed on other nodes so that I could avoid redelivering them > > again. > > > > Sorry if thats a bit vague - I am fishing for ideas …. > > > > > > Thanks and best regards > > Andreas >
