Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of ke1g.nh@gmail.com designates
 209.85.219.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6A9AAE03-AB87-4DBA-AEC7-D1080C26D2A8@blueyonder.co.uk>
References: 
 <CAB+Aj0t4z6mRXZii=bV8bwBoS5FAfbsgmJR6GZJM8zkTFDHaVg@mail.gmail.com>
	<CAB+Aj0vHSNY8pjoeOtcxwQT8ackunYDUZTDhMVDjdi-e6_BksA@mail.gmail.com>
	<51559722.7000604@redhat.com>
	<CAB+Aj0uABta2AyY9K8jfHa-=Fh=T7OKLtpr9gdj=zJtFvKD7Nw@mail.gmail.com>
	<51594D49.7090605@redhat.com>
	<CAB+Aj0trjZAW5aMHFs6++P0v6OfaxDBUM2_YKzpBxvbUF5axPw@mail.gmail.com>
	<CAB+Aj0vs5aSKEhyEUsPfms+RNu3zVM5SzfQnYdjL6yuq2qwiZg@mail.gmail.com>
	<51599A8B.6080308@redhat.com>
	<178027859.118135.1364830592472.JavaMail.root@redhat.com>
	<CAB+Aj0uy_KrcwAE+AzOC4SfyGTY2Sec5tgkrgWzE2ocyyxf4hw@mail.gmail.com>
	<5159B3F1.3030804@redhat.com>
	<CAB+Aj0snDjRhV_m+JQWN4nVYjvd=1zR0LSwb=F0PfgZ66mE-cw@mail.gmail.com>
	<6A9AAE03-AB87-4DBA-AEC7-D1080C26D2A8@blueyonder.co.uk>
Date: Mon, 1 Apr 2013 14:56:23 -0400
Message-ID: 
 <CAB+Aj0uqwRK0_E7OaFnMcjjgRKCjuOSekaC0sWvUY72Lk9e4fg@mail.gmail.com>
Subject: Re: Questions from a novice
From: Bill Freeman <ke1g.nh@gmail.com>
To: users@qpid.apache.org
Content-Type: multipart/alternative; boundary=089e01184bcc5b4c3304d9512db6

--089e01184bcc5b4c3304d9512db6
Content-Type: text/plain; charset=ISO-8859-1

Fraser,

See below, time permitting.

On Mon, Apr 1, 2013 at 2:12 PM, Fraser Adams
<fraser.adams@blueyonder.co.uk>wrote:

> Firstly to say that I'm currently on holiday under a qpid curfew :-) so I
> can only sneak in a quick response at the moment, I'll try to give some
> proper answers to questions posed in this thread later on in the week.
>
> On Gordon's --mgmt-qmf1=false I "thought" those broker flags only actually
> related to "push" messages sent from the broker, so that"s things like
> heartbeats and the broker "data push" that can be subscribed to, I'm pretty
> sure that the request/response stuff is driven by the address used, for
> example qmf2 uses qmf.default.direct or qmf.default.topic, for qmf1 there's
> another address qpid.management??? - I'd need to check. Anyway I think
> that's how you'd select between QMF2 and QMF1 for request response type
> things. The python APIs do this transparently under the hood.
>


I believe that I fall into the data push camp, even though I may not be
using the modern means of achieving it.  I create my qmf.console.Session
instance with rcvObjects = True.  Then, after an initial one copy of
everything, I'm only sent updates if anything changes, and then at most
once every 10 seconds.  I don't want to poll.  So maybe the flag works
(though I have other concerns about a broker wide, rather than connection
or even session specific setting).


> there's been some talk about ObjectIds, now it is true to say that V2
> ObjectIds comprise a Map that may have some meaningful names, but the qmf2
> API spec says that they are supposed to be opaque, the python lib tools
> have definitely "interpreted" them, but I'm not personally convinced that
> that's a great idea. I've certainly avoided interpreting them in anything
> I've done with QMF. To be fair it is all a bit ambiguous give that the
> names in the protocol suggest something, but as I say the QMF2 API doc
> definitely says opaque, but then again the API seems to have fallen against
> the wayside rather, which is kind of a shame.
>


Whatever its called, I need some kind of key to disambiguate objects.  I
need them to be consistent across restarts of the broker, and maybe even
across some minor reconfiguration of the broker that is outside of my
control (such as the deletion and/or addition of queues, exchanges, and
bindings).  Since I will be talking to multiple brokers, I need to guard
against the possibility that a key could be repeated in a second broker
(particularly when multiple brokers are federated to duplicate efforts as a
fallback if one crashes).


> One comment for Bill, the GUI that I put together has been mentioned, it's
> worth taking a look at, in particular it's not just a GUI, it's backed by a
> Java implementation of the documented QMF API, so if your Web server is
> Java based that might be more convenient to use that a python API. There is
> also a Rest API for QMF and a JavaScript API that is backed by the Rest API.
>


I'm much better at Python than I am at Java, and my web server (which
doesn't speak QMF anyway, being isolated by REDIS) is tornado, a python
based tool.  And Rest doesn't sound promising for getting updates pushed to
me.


> One last thing, there is some discussion beginning about the future of
> management, the eventual intention is to move away from QMF towards a new
> AMQP management API, however that is in the very early stages so at the
> moment QMF is the only game in town for C++ broker management. There are a
> few of us very keen to make sure that transition to the new API is as
> painless as possible, but as I say it's very very early days and is mainly
> said to try to ensure that you bear it in mind with your application. I'd
> very definitely avoid QMF1 though QMF2 is a better bet.
>


And my target brokers, which I don't get to specify, are C++ brokers.


>
> I'll try to give some slightly deeper responses later in the week,
> HTH,
> Fraser
>


Have a good rest of your vacation, and thanks.

Bill

--089e01184bcc5b4c3304d9512db6--