Hi Audun, can you create a test case that reproduces this problem. If so, it'd be great to submit it to Jira. Also, I see you're using quite small figures for timeout and delay (10 ms) which is quite aggressive in terms how often backup transport tries to establish the connection. Can you try with some larger values, like 1000 (1s) and see if the problem persists.
Regards -- Dejan Bosanac ---------------------- Red Hat, Inc. FuseSource is now part of Red Hat [email protected] Twitter: @dejanb Blog: http://sensatic.net ActiveMQ in Action: http://www.manning.com/snyder/ On Fri, Dec 6, 2013 at 10:09 AM, Audun Fauchald Strand < [email protected]> wrote: > We have 4 clients publishing to a virtual-topic, and 4 instances of an > application with 15 consumers consuming messages from that topic. > > The topic is running on two servers (A and B) with a duplex networkconencts > from A to B. > Thw transportConnector is set up with setUpdateClusterClientsOnRemove and > setUpdateClusterClients to true. > > The failover configuration is as follows: > > Publishers: > > failover:(tcp://A)?randomize=false&backup=true&timeout=10&priorityBackup=true&maxReconnectDelay=10&maxReconnectAttempts=1&trackMessages=true > > Consumers: > > failover:(tcp://A)?randomize=false&backup=true&priorityBackup=true&maxReconnectDelay=10&maxReconnectAttempts=1 > > We deploy to half the instances of the modules at the time, so that we have > no downtime. > > When stopping and deploying to A, we se that all publisher and consumers > goes to B, but when A comes up again, one of the four publisher instances > keeps publishing to B while the rest of the publishers, and all the > consumers goes back to A. This results in a lot of messages never being > consumed. > > The logs shows that the publisher successfully connects to A after A is up > again, but this isntt reflected in where the mesages are published. > > > -- > Audun Fauchald Strand >
