That does look like strange behavior. I think you should reopen AMQ-2327 with your test case. There may be a better way to resolve that issue that does not introduce ordering dependencies. The test case attached to AMQ-2327 is the best focus to understand the original use case but I think this may be a tricky one to sort out. We will try and get to the bottom of this for the 5.8 release.
On 19 November 2012 21:28, Guerrero <[email protected]> wrote: > I am using activemq-core-5.7.0. > > We are using broker-to-broker communications with conduit subscriptions to > reduce redundant messaging. We have a top-tier coordinating server, call it > broker A. We have two routing servers that each connect to A, call them > broker B and broker C. We have remote applications that connect to both B > and C for redundancy, and client applications that connect to only one of B > or C. We only use topic messages for all communications between nodes. > <http://activemq.2283324.n4.nabble.com/file/n4659548/network.png> > Normally, all is well. However, we noticed some problems in the remaining > network when nodes were lost. We were able to find steps to recreate the > problem as follows. Start the nodes in the order A, B, C, Remote, Client1, > Client2. Stop node C. At this point, some of the consumers from the > Remote > were lost from Client1, while others remained. If we send a message from > Client1 on one of the topics that was lost, it doesn't leave the local > broker. > > Tracing into the source of the network bridge, I suspected that > ConduitBridge.checkPaths was preventing one of the consumer paths from > being > added to the list. I've attached a unit test, ConduitMockTest.java > <http://activemq.2283324.n4.nabble.com/file/n4659548/ConduitMockTest.java> > , that uses JUnit, EasyMock, and activemq, that shows how messages may stop > forwarding depending on the order the consumers are added and removed from > the network bridge. > > When I comment out the check for checkPaths, my test and our application > seem to work. However, ThreeBrokerQueueNetworkTest.testDuplicateQueueSubs > fails. I traced back the addition of checkPaths as a fix for AMQ-2327 > <https://issues.apache.org/jira/browse/AMQ-2327> , but cannot understand > why duplicate paths would be suppressed like this, when there is a flag to > suppress duplicate subscriptions for topics and queues and this is checked > elsewhere. > > Can anyone add any insights into why checkPaths exists, or what could be > wrong with the attached test case for addAndRemoveSameOrder()? > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Topic-consumers-are-lost-in-a-cyclic-network-tp4659548.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- http://redhat.com http://blog.garytully.com
