Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of gary.tully@gmail.com designates
 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1353360522123-4659548.post@n4.nabble.com>
References: <1353360522123-4659548.post@n4.nabble.com>
Date: Tue, 20 Nov 2012 10:58:22 +0000
Message-ID: 
 <CAH+vQmN18G0Qnw6dQKJ5de2iVchShYSRZahoX0ZDFayzPwVs=Q@mail.gmail.com>
Subject: Re: Topic consumers are lost in a cyclic network
From: Gary Tully <gary.tully@gmail.com>
To: "users@activemq.apache.org" <users@activemq.apache.org>
Content-Type: multipart/alternative; boundary=0016e6d58ce9c90bc004ceeb1cb9

--0016e6d58ce9c90bc004ceeb1cb9
Content-Type: text/plain; charset=ISO-8859-1

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 <guerreroderrick@gmail.com> 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

--0016e6d58ce9c90bc004ceeb1cb9--