Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAMsD-yDm=JgqLCNxCCL6_Om-L2_KSH=5Faxa-RAon+d-n1KwGg@mail.gmail.com>
References: 
 <CAMsD-yDEJ3Wcnv5NkPDHfp2n36APFhsj5haFrKJOwomz6275fg@mail.gmail.com>
	<568D2EC0.5090401@redhat.com>
	<CAMsD-yDm=JgqLCNxCCL6_Om-L2_KSH=5Faxa-RAon+d-n1KwGg@mail.gmail.com>
Date: Wed, 6 Jan 2016 11:14:39 -0500
Message-ID: 
 <CAMsD-yBWL9UN_ig2ikSb4K9mkQ6YLnBn7tmzfo3cxDFdF9HGng@mail.gmail.com>
Subject: Re: [C++ Broker] dynamically federated links
From: Matt Broadstone <mbroadst@gmail.com>
To: users <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=001a113b0244abaa690528aca63b

--001a113b0244abaa690528aca63b
Content-Type: text/plain; charset=UTF-8

On Wed, Jan 6, 2016 at 10:23 AM, Matt Broadstone <mbroadst@gmail.com> wrote:

> On Wed, Jan 6, 2016 at 10:12 AM, Ted Ross <tross@redhat.com> wrote:
>
>> On 01/06/2016 10:03 AM, Matt Broadstone wrote:
>>
>>> I'm having some trouble linking two brokers together using the
>>> documentation in section 1.4 (Broker Federation), and was looking for
>>> some
>>> advice.
>>>
>>> * I currently have two brokers (192.168.1.1, 192.168.1.2) which use PLAIN
>>> SASL, and have appropriate ACL files allowing a user "test" access to
>>> everything once authenticated.
>>>
>>> * I then have two previously existing (not sure if this is where the
>>> problem starts, very little guiding debug information is printed) durable
>>> fanout topics on each broker called `test.fanout` -- this is the
>>> "initial"
>>> unfederated state.
>>>
>>> * At this point I run the following command on 192.168.1.2, in order to
>>> dynamically federate the `test.fanout` exchange to the "leader":
>>>
>>> qpid-route -v dynamic add test/password@192.168.1.1:5672
>>>>
>>> test/password@localhost:5672 test.fanout
>>>
>>
>> I wonder if you are running into problems because you used "localhost"
>> instead of the real address (192.168.1.2).  Both systems think of
>> themselves as localhost so there may be a collision.
>
>
> Ted,
> That looks like it solved the problem! Many thanks.  Might I suggest an
> update to the documentation to remove all references to localhost.  Also
> there is a typo in the federation docs about `qpid-route list connections`
> which is a command that does not exist, rather it shouldbe `qpid-route link
> list`
>
> Cheers,
> Matt
>
>
Just one more question that doesn't seem to be covered in the
documentation: is it possible with just `qpid-route` to configure
replication of queues across federated brokers?  It seems that the
`qpid-route queue` related commands all bind a given queue to a remote
exchange, where ideally it would be possible to federate two brokers and
maintain a shared queue between them.

Matt


>
>>
>>
>>> Link state is Operational
>>> Creating inter-broker binding...
>>> Bridge method returned: 0 OK
>>>
>>> * Cool, seems like everything worked. However, on the other side my qpidd
>>> log file has the following:
>>>
>>> 2016-01-06 09:50:58 [Management] error Detected two management objects
>>> with
>>> the same identifier:
>>>
>>> 0-3-1--653(org.apache.qpid.broker:session:test@TEST.qpid.bridge_session_qpid.tcp
>>>
>>> :localhost:5672!test.fanout!test.fanout!_25c065aa-5b1b-465a-a6d2-510666f89248)
>>>
>>> which seems problematic, however the link is operational and there are no
>>> other errors.
>>>
>>> * Now I try to use the fanout by connecting to the local broker on
>>> 192.168.1.2 and sending some data. The data is indeed sent to the local
>>> fanout and I'm able to pick up those messages, but nothing is sent to the
>>> federated broker.
>>>
>>> Any hints as to where I'm going wrong here would be much appreciated!
>>>
>>> Matt
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>

--001a113b0244abaa690528aca63b--