You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Fraser Adams <fr...@blueyonder.co.uk> on 2012/05/06 12:37:25 UTC
QMF2 doesn't seem to behave as expected in federated network
Hi all,
I'm looking through a bunch of QMF2 object properties and statistics and
things don't seem to add up (all qpid 0.12)
I've stood up two brokers and have created a source queue route between
them
qpid-config add queue federate --limit-policy=ring
qpid-config bind amq.match federate fedkey all
data-service=amqp-delivery
qpid-route -s queue add localhost:5673 localhost:5672 amq.match
federate
However I cut this, whether I use source routes or standard routes or
whether I do qpid-config -a localhost:5673 etc. and fire up the route in
the opposite direction the same general thing happens (or rather
doesn't!!!!!!).
I'd have expected the connection QMF objects describing the inter broker
connection to give a little more info....
The federationLink and systemConnection properties remain resolutely
"false" when that's definitely not the case and incoming remains "true"
whatever I do. Is there any point to these properties? am I doing
something wrong? There seems no point in presenting the info from them
in my application as the information seems very misleading.
Also the remote process name and remote PID property seems to be unset
on federated links, it might be nice if it was set to qpidd.
Also looking through the QMF2 project page documentation
https://cwiki.apache.org/qpid/qmfv2-project-page.html there is a
paragraph thus:
*Federation is supported.* In QMFv1, messages cannot be transferred over
federation links between brokers. Each broker represents its own
isolated QMF domain. In QMFv2, agents and consoles can connect to any
broker in a federated network and interact with other agents and
consoles anywhere in the network.
So what this seems to be implying is that should I connect a QMF2
Console to any broker in a federated network I *should* be able to see
information for any broker in the network, this doesn't *seem* do be
happening. Is this mode of operation actually supported, is there
anything that I need to do? getObjects("broker") seems to resolutely
only return a single entry.
Cheers,
Frase
Re: QMF2 doesn't seem to behave as expected in federated network
Posted by Robbie Gemmell <ro...@gmail.com>.
On 6 May 2012 11:37, Fraser Adams <fr...@blueyonder.co.uk> wrote:
> Hi all,
<snip>
>
> Also looking through the QMF2 project page documentation
> https://cwiki.apache.org/qpid/qmfv2-project-page.html there is a paragraph
> thus:
>
> *Federation is supported.* In QMFv1, messages cannot be transferred over
> federation links between brokers. Each broker represents its own isolated
> QMF domain. In QMFv2, agents and consoles can connect to any broker in a
> federated network and interact with other agents and consoles anywhere in
> the network.
>
>
> So what this seems to be implying is that should I connect a QMF2 Console to
> any broker in a federated network I *should* be able to see information for
> any broker in the network, this doesn't *seem* do be happening. Is this mode
> of operation actually supported, is there anything that I need to do?
> getObjects("broker") seems to resolutely only return a single entry.
>
>
> Cheers,
> Frase
>
>
Hi Fraser
I can't really speak to how it should/does work, or any of the other
stuff which I snipped out, but I thought I'd reply on this bit to say
thats not how I would read the quoted section. What I think it is
saying is that if you wanted to you could have a set of federated
brokers with your own agents and consoles connected to them and
organise things such that you can connect consoles to any of the
brokers and interact with any of the agents (/with each other) using
QMF 2, but not using QMF 1 where you could only contact agents
connected to the same broker. I'm not sure it is really talking about
the brokers own internal management Agent at all.
With that said, I will now defer to someone who might actually know for sure :)
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: QMF2 doesn't seem to behave as expected in federated network
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi again all,
just prodding again to see if anyone has any more thought on this, in
particular:
The federationLink and systemConnection properties remain resolutely
"false" when that's definitely not the case and incoming remains "true"
whatever I do. Is there any point to these properties? am I doing
something wrong? There seems no point in presenting the info from them
in my application as the information seems very misleading.
do these actually change in any circumstance, as far as I have seen they
don't :-(
Also are there any more thoughts about what QMF2 is *supposed* to do in
a federated network. The wiki says that federation is supported but I
can't see how one would use it, has anyone tried to use QMF2 in a
federated network? I can clearly connect to each broker in turn but
that's a bit tedious.
Re "In QMFv2, agents and consoles can connect to any broker in a
federated network and interact with other agents and consoles anywhere
in the network." what does this *actually* mean in practice and what
would I have to put in place to make it meaningful, would I have to
explicitly add routes between the qmf exchanges? how would I establish
bidirectional comms (any broker anywhere in the network) without
introducing looping. Some examples here would be useful, clearly I'm
missing something.
Cheers,
Frase
On 06/05/12 11:37, Fraser Adams wrote:
> Hi all,
> I'm looking through a bunch of QMF2 object properties and statistics
> and things don't seem to add up (all qpid 0.12)
>
> I've stood up two brokers and have created a source queue route
> between them
>
> qpid-config add queue federate --limit-policy=ring
> qpid-config bind amq.match federate fedkey all
> data-service=amqp-delivery
> qpid-route -s queue add localhost:5673 localhost:5672 amq.match
> federate
>
> However I cut this, whether I use source routes or standard routes or
> whether I do qpid-config -a localhost:5673 etc. and fire up the route
> in the opposite direction the same general thing happens (or rather
> doesn't!!!!!!).
>
> I'd have expected the connection QMF objects describing the inter
> broker connection to give a little more info....
>
> The federationLink and systemConnection properties remain resolutely
> "false" when that's definitely not the case and incoming remains
> "true" whatever I do. Is there any point to these properties? am I
> doing something wrong? There seems no point in presenting the info
> from them in my application as the information seems very misleading.
>
> Also the remote process name and remote PID property seems to be unset
> on federated links, it might be nice if it was set to qpidd.
>
>
> Also looking through the QMF2 project page documentation
> https://cwiki.apache.org/qpid/qmfv2-project-page.html there is a
> paragraph thus:
>
> *Federation is supported.* In QMFv1, messages cannot be transferred
> over federation links between brokers. Each broker represents its own
> isolated QMF domain. In QMFv2, agents and consoles can connect to any
> broker in a federated network and interact with other agents and
> consoles anywhere in the network.
>
>
> So what this seems to be implying is that should I connect a QMF2
> Console to any broker in a federated network I *should* be able to see
> information for any broker in the network, this doesn't *seem* do be
> happening. Is this mode of operation actually supported, is there
> anything that I need to do? getObjects("broker") seems to resolutely
> only return a single entry.
>
>
> Cheers,
> Frase
>
>
>
>
>