Looked briefly at your configs... Can you try this... for the brokers that have 2+, you can use the masterslave: discovery agent on your network connector... check out more details here: http://activemq.apache.org/networks-of-brokers.html
For the NC that has single URI connectons, add this to the failover URI: ?&maxReconnectAttempts=0 If that doesn't help, update the JIRA with this info and we can take a look.. On Wed, Sep 11, 2013 at 4:56 AM, Andy May <andrew....@bcpsoftware.com>wrote: > I'm using a network of brokers & am trying to get a fail-back network > connection working (using priorityBackup=true on the connector) > > I'm finding that the broker does failover & failback correctly but that the > remote broker doesn't seem to recognise that the re-established connection > is a network connection. Because of this, it rejects messages because of > duplicate producer-sequences (even though the producerID is different). > > I've logged the issue on JIRA ( > https://issues.apache.org/jira/browse/AMQ-4720 > <https://issues.apache.org/jira/browse/AMQ-4720> ) & have attached a > test-script + config-files + log-files there. > > > /Does anyone know of any configuration changes that I could make to avoid > this problem? > (Or can anyone recommend a different configuration that would meet my > needs?) / > > > Details of why I'm trying this configuration: > > > Use case: > > > 1 central site. > Multiple branches, each with a single branch server and multiple user PCs. > Each branch only has 1 internet connection that is shared by branch server > & > PCs. > Branch server is typically unreliable hardware & may go offline without > notice. > Resilience to network loss is important & so each PC & server has its own > broker. > Both branch server & PCs need to be able to communicate with the centre > > To reduce the number of connections into the centre, we would like a tree > topology with the branch server concentrating all branch PC messages & > forwarding them to the centre. > But, PCs generate a data feed that we want to be able to access at centre, > even when the branch server is offline. > > Proposed configuration: > > Use a failover network connection on branch PCs & configure the connection > to prioritise a connection to the branch server, but open a direct > connection to the centre if the branch server is unavailable. > > > Details of configuration > > Using ActiveMQ 5.8.0 binary download. > Only changes are to logging settings & to the configuration file. > > 3 brokers ("amq1", "amq2", "amq3"), all brokers running on localhost. > Each uses their own config file (amq1.xml, amq2.xml, amq3.xml) > > Broker amq1 has a failover duplex connection to amq2. > Broker amq3 has a duplex failover connection to both amq1 + amq2, it is > configured to always try to connect to amq1 first ("randomize=false") and > to > fail-back to amq1 if it comes back online ("priorityBackup=true") > > Consumer connects to broker amq1 > Producer connects to broker amq3 > > Test-harness sender application creates a new session each time it is run & > sends a set of messages. > The sending session is not transacted & is set to auto-acknowledge. > Messages are sent with persistent delivery mode. > > Config files > > amq1.xml <http://activemq.2283324.n4.nabble.com/file/n4671409/amq1.xml> > amq2.xml <http://activemq.2283324.n4.nabble.com/file/n4671409/amq2.xml> > amq3.xml <http://activemq.2283324.n4.nabble.com/file/n4671409/amq3.xml> > > Test script > > Test-script.txt > <http://activemq.2283324.n4.nabble.com/file/n4671409/Test-script.txt> > > Log files from test > > amq1.log <http://activemq.2283324.n4.nabble.com/file/n4671409/amq1.log> > amq2.log <http://activemq.2283324.n4.nabble.com/file/n4671409/amq2.log> > amq3.log <http://activemq.2283324.n4.nabble.com/file/n4671409/amq3.log> > > > > > > > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Need-help-Messages-lost-when-using-failover-network-connection-with-failback-tp4671409.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta
