Using QMF to know about consumers in a topic exchange

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Using QMF to know about consumers in a topic exchange

mottese
Hi,

Suppose I have a consumer listening to amq.topic/mySubject. Can I use QMF to tell if I have a consumer listening to that address? Right now I am trying to use a message formatted like this:

    Message request;
    request.setReplyTo(replyToAddress);
    request.setProperty("x-amqp-0-10.app-id", "qmf2");
    request.setProperty("qmf.opcode", "_query_request");
    Variant::Map schemaId, content;
    schemaId["_class_name"] = "queue";
    schemaId["_object_name"] = "org.apache.qpid.broker:queue:amq.topic/mySubject";
    content["_what"] = "OBJECT";
    content["_object_id"] = schemaId;
    request.setContentObject(content);

Is there some way to modify this QMF request to get the information I'm looking for? Thanks

Max
Reply | Threaded
Open this post in threaded view
|

Re: Using QMF to know about consumers in a topic exchange

Gordon Sim
On 26/05/17 16:07, mottese wrote:

> Hi,
>
> Suppose I have a consumer listening to amq.topic/mySubject. Can I use QMF to
> tell if I have a consumer listening to that address? Right now I am trying
> to use a message formatted like this:
>
>     Message request;
>     request.setReplyTo(replyToAddress);
>     request.setProperty("x-amqp-0-10.app-id", "qmf2");
>     request.setProperty("qmf.opcode", "_query_request");
>     Variant::Map schemaId, content;
>     schemaId["_class_name"] = "queue";
>     schemaId["_object_name"] =
> "org.apache.qpid.broker:queue:amq.topic/mySubject";
>     content["_what"] = "OBJECT";
>     content["_object_id"] = schemaId;
>     request.setContentObject(content);
>
> Is there some way to modify this QMF request to get the information I'm
> looking for? Thanks
You need to query the bindings. The attached program will list all the
bindings. You could modify the approach to filter out all but those
where the exchange is "amq.topic". (You can't have the query do that
filtering for you with QMF).



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

list_bindings.cpp (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using QMF to know about consumers in a topic exchange

mottese
I'm running that test program, but I noticed that I never receive a response. I modified the connection to be:

  Connection c(argc > 1 ? argv[1] : "localhost"); //, "{protocol:amqp1.0}");

And that worked. Any idea why this would change things?
Reply | Threaded
Open this post in threaded view
|

Re: Using QMF to know about consumers in a topic exchange

Gordon Sim
On 26/05/17 18:09, mottese wrote:
> I'm running that test program, but I noticed that I never receive a response.
> I modified the connection to be:
>
>   Connection c(argc > 1 ? argv[1] : "localhost"); //, "{protocol:amqp1.0}");
>
> And that worked. Any idea why this would change things?

Does your broker (and/or client) have AMQP 1.0 enabled? If you run with
QPID_LOG_ENABLE=trace+ it should give some more insight into what was
going wrong over 1.0.

Without that it will use AMQP 0-10. Does it matter to you which protocol
you use? As it is QMF and the qpidd specific schema, it won't limit
interop. It would only be an issue if you wanted to turn off 0-10.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Using QMF to know about consumers in a topic exchange

mottese
This post was updated on .
Gordon Sim wrote
Does your broker (and/or client) have AMQP 1.0 enabled?
When I start up the broker it says:

  [Broker] info Loaded protocol amqp1.0

I know when I built my C++ client, there was some kind of log message saying AMQP 1.0 was enabled. How can I verify that? I will mess around with it a bit more to see if I can find anything else going on.
Reply | Threaded
Open this post in threaded view
|

Re: Using QMF to know about consumers in a topic exchange

mottese
In reply to this post by Gordon Sim
Gordon Sim wrote
If you run with
QPID_LOG_ENABLE=trace+ it should give some more insight into what was
going wrong over 1.0.
I turned on trace+, but all I seem to be seeing is a whole bunch of the same message:

  [Broker] trace Dispatching to xxxxxxx#_yyyyyyy: 0
  [Broker] trace Can't deliver to xxxxxxx#_yyyyyyy

I looked earlier in the log and it looks like it was able to successfully create the response queue.
Reply | Threaded
Open this post in threaded view
|

Re: Using QMF to know about consumers in a topic exchange

Gordon Sim
On 26/05/17 18:44, mottese wrote:

> Gordon Sim wrote
>> If you run with
>> QPID_LOG_ENABLE=trace+ it should give some more insight into what was
>> going wrong over 1.0.
>
> I turned on trace+, but all I seem to be seeing is a whole bunch of the same
> message:
>
>   [Broker] trace Dispatching to xxxxxxx#_yyyyyyy: 0
>   [Broker] trace Can't deliver to xxxxxxx#_yyyyyyy
>
> I looked earlier in the log and it looks like it was able to successfully
> create the response queue.
Sorry, my mistake. Not sure why the protocol was to 1.0 in that, it
looks like it was only used on 0-10. (It was a program I had lying
around from a previous request).

Attached is a revised version that works with AMQP 1.0. It uses the
Receiver::getAddress() to correctly set the reply to address. I also
updated it to use the content object methods for the message rather than
the 0-10 specific encode/decode methods.

I've tried it out myself this time before sending(!) and it works as
expected.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

list_bindings.cpp (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Using QMF to know about consumers in a topic exchange

Chris Richardson
I wrote a library to support this type of thing a while ago. I've just
added an example equivalent to Gordon's (there may be some slight
similarities ;) ) to show the retrieval of bindings:
https://github.com/fourceu/fourc-qpid-manager/blob/master/examples/Bindings.cxx

The library hides the complications of the QMF RPC and hides
complications like responses split across several messages (which will
happen when you have more than ~100 bindings on your broker).

Peer review of the library is more than welcome :)

Chris


On 26 May 2017 at 19:40, Gordon Sim <[hidden email]> wrote:

> On 26/05/17 18:44, mottese wrote:
>>
>> Gordon Sim wrote
>>>
>>> If you run with
>>> QPID_LOG_ENABLE=trace+ it should give some more insight into what was
>>> going wrong over 1.0.
>>
>>
>> I turned on trace+, but all I seem to be seeing is a whole bunch of the
>> same
>> message:
>>
>>   [Broker] trace Dispatching to xxxxxxx#_yyyyyyy: 0
>>   [Broker] trace Can't deliver to xxxxxxx#_yyyyyyy
>>
>> I looked earlier in the log and it looks like it was able to successfully
>> create the response queue.
>
>
> Sorry, my mistake. Not sure why the protocol was to 1.0 in that, it looks
> like it was only used on 0-10. (It was a program I had lying around from a
> previous request).
>
> Attached is a revised version that works with AMQP 1.0. It uses the
> Receiver::getAddress() to correctly set the reply to address. I also updated
> it to use the content object methods for the message rather than the 0-10
> specific encode/decode methods.
>
> I've tried it out myself this time before sending(!) and it works as
> expected.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]



--
Chris Richardson, System Architect
[hidden email]

FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norway
www.fourc.eu

Follow us on LinkedIn, Facebook, Google+ and Twitter!

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]