qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: qmf2 broker stats sample
Date Tue, 26 May 2015 18:17:07 GMT
On 05/26/2015 06:12 PM, Matt Broadstone wrote:
> On Tue, May 26, 2015 at 12:06 PM, Matt Broadstone <mbroadst@gmail.com>
> wrote:
>
>> Hi all,
>>
>> I have two sample C++ applications (provided by chug on irc, previously
>> provided by gsim iirc) using the qpid C++ messaging api, that connect to a
>> broker and use qmf2 to retrieve broker statistics:
>>
>> The first one, here (https://gist.github.com/mbroadst/4c24416bbaebdf56998a)
>> I believe uses amqp 0-10 (the default wire protocol), and indeed prints out
>> broker statistics when run.
>>
>> The second one, here (
>> https://gist.github.com/mbroadst/54a3d75779c0c63ed30c) forces the use of
>> AMQP 1.0, by passing "{ protocol: amqp1.0 }" to the Connection ctor, and
>> does not work but simply spins waiting for responses once run.
>>
>> This has been verified to be the case on ubuntu (where I am running it),
>> as well as Fedora (by mcpierce).
>>
>> Cheers,
>> Matt
>>
>
> It looks like the error in this case is specific to the "#" identifier used
> for the responses Address on L43. If I replace this with "test" I do indeed
> get a response, however I also now get this error:
>
> ERROR: illegal-argument: Not enough data for list, expected 3506438148
> bytes but only 1137 available
> (/build/buildd/qpid-cpp-0.32/src/qpid/framing/List.cpp:59)

The example you have relies on the way 0-10 works for temporary queue 
names and for encoding the map data.

For the first issue, just use "#" for the receiver and instead of an 
explicit Address object, use receiver.getAddress() as the value for 
reply-to. That will work whether the name is generated client side (as 
in 0-10) or server side (as in 1.0).

For the second use the get-/set-ContentObject() methods rather than 
decode/encode. The 'usual' 1.0 encoding of structured is not based on a 
content-type which necessitated a small APi change. The content object 
approach works with either protocol.

E.g. see attached example that is mostly the same as yours (I think) 
other than these fixes.


Mime
View raw message