Return-Path: 
 <users-return-30606-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org>
X-Original-To: apmail-activemq-users-archive@www.apache.org
Delivered-To: apmail-activemq-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 98E9C9E45
	for <apmail-activemq-users-archive@www.apache.org>;
 Thu,  5 Apr 2012 17:57:04 +0000 (UTC)
Received: (qmail 37535 invoked by uid 500); 5 Apr 2012 17:57:04 -0000
Delivered-To: apmail-activemq-users-archive@activemq.apache.org
Received: (qmail 37498 invoked by uid 500); 5 Apr 2012 17:57:04 -0000
Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@activemq.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@activemq.apache.org>
List-Post: <mailto:users@activemq.apache.org>
List-Id: <users.activemq.apache.org>
Reply-To: users@activemq.apache.org
Delivered-To: mailing list users@activemq.apache.org
Received: (qmail 37490 invoked by uid 99); 5 Apr 2012 17:57:04 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Apr 2012 17:57:04 +0000
X-ASF-Spam-Status: No, hits=2.2 required=5.0
	tests=HTML_MESSAGE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: local policy)
Received: from [188.65.46.139] (HELO mail.arise.pl) (188.65.46.139)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Apr 2012 17:56:54 +0000
Received: from localhost (localhost [127.0.0.1])
	by mail.arise.pl (Postfix) with ESMTP id 0B7513ABB94;
	Thu,  5 Apr 2012 19:57:20 +0200 (CEST)
X-Virus-Scanned: amavisd-new at arise.pl
Received: from mail.arise.pl ([127.0.0.1])
	by localhost (mail1.arise [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id WxugqQVmClKS; Thu,  5 Apr 2012 19:57:19 +0200 (CEST)
Received: from mail1.arise (mail1.arise [192.168.198.7])
	by mail.arise.pl (Postfix) with ESMTP id 5E1F53ABB95;
	Thu,  5 Apr 2012 19:57:19 +0200 (CEST)
Date: Thu, 5 Apr 2012 19:57:19 +0200 (CEST)
From: Marcin Giedz <marcin.giedz@arise.pl>
To: users@activemq.apache.org
Message-ID: <1308923595.151043.1333648639224.JavaMail.root@mail1>
In-Reply-To: <759032046.150585.1333646162221.JavaMail.root@mail1>
Subject: AMQ 5.6 vs 5.5 - network of brokers
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_151042_297917136.1333648639223"
X-Originating-IP: [77.79.237.84]
X-Mailer: Zimbra 7.1.4_GA_2555 (ZimbraWebClient - GC18 (Linux)/7.1.4_GA_2555)

------=_Part_151042_297917136.1333648639223
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi all, 


Just wanted to try out a new 5.6 version with such configuration: 


a) broker A - on this broker several services are running like XX, YY, ZZ. All these services create queues like pl.arise.XX etc 

<networkConnectors> 
<networkConnector uri="static:(tcp://172.16.36.7:61616)"> 
<dynamicallyIncludedDestinations/> 
<excludedDestinations> 
<queue physicalName="pl.arise.XX"/> 
<queue physicalName="pl.arise.YY"/> 
</excludedDestinations> 
</networkConnector> 
</networkConnectors> 


b) broker B - on this broker the same services are running except for ZZ. ZZ stream is taken from broker A so statical include is added 

<networkConnectors> 
<networkConnector uri="static:(tcp://192.168.89.14:61616)" destinationFilter="NO_DESTINATION"> 
<staticallyIncludedDestinations> 
<queue physicalName="pl.arise.ZZ"/> 

</staticallyIncludedDestinations> 
</networkConnector> 
</networkConnectors> 


This configuration works really great with 5.5.1 (FUSE version) which means: on broker A, XX service sends PING message periodically to local service ZZ on pl.arise.ZZ but non of these ping messages are passed to broker B on his pl.arise.ZZ!!!! 


With the same configuration (only destinationFilter is changed to staticBridge although both were checked) situation is that: when on broker A, XX service sends PING message this message is passed to broker B on pl.arise.ZZ but not broker A... in this case service XX on broker A doesn't get any feedback from local service ZZ and assumes service is down. It simply looks like broker B is stealing messages which are dedicated for broker A. 


Service ZZ can be ran only ONCE. That's why it is running on broker A. When CONSUMER connected to broker B wants stream from ZZ service then it connects to ZZ via included queue on his broker B from broker A. Even if there is no consumer on broker B connected to pl.arise.ZZ messages appear on broker B. What happened between these two releases in this case? What is the proper way this should work - I mean either 5.5.1 is broker and what I take as "good solution" is rather a BUG or 5.6 has a BUG. 


Thank you! 
M. 
------=_Part_151042_297917136.1333648639223--