Hi Davide. Re "Today I came across this: http://ci.apache.org/projects/qpid/apis/0.10/cpp/html/a00461.html and I wonder whether this API is currently actively developed or is deprecated. Examples on the Qpid distribution for Windows use this API and they seems to be doing exactly what I am looking for. " That's the one I was referring to when I said "there's also a C++ API for QMF2 but unfortunately that bears no relation whatsoever to the API specified off the wiki???" which is specified at https://cwiki.apache.org/qpid/qmfv2-project-page.html I'm afraid that I've got no idea as to whether this is in active development or not and is partly why I was saying earlier that QMF is rather disjoint. I'm pretty sure that that the C++ API does actually use the QMF2 *protocol* under the hood but clearly it bears little relation to the QMF2 API I've linked above. My Java QMF2 API implementation is a pretty much complete implementation of the QMF2 API including things like query subscriptions the C++ API only supports some features (the subscribe call is just a stub) and I *think* though I'm not massively familiar with that API that it only supports an asynchronous model so the getObjects() type calls that you may be familiar with from the QMF1 API aren't present. With respect to your core problem space are your "satellite components" messaging applications or are they brokers themselves, I'm guessing the former. You said earlier "but I guess I can achieve the same result with the QMF, getting notification on connect and disconnect events. " that should be possible with QMF but in basic terms that will only tell you the IP of the host so you'd need to know a priori what *should* be present to give an indication of whether it exists or not. In case it helps you in any way I've attached another python QMF1 application I put together, it's a connection audit mechanism. The idea with this is that I wanted to validate consumers against a whitelist without having to resort to full authentication so the QMF application checks connections and for each connection checks the queue associated with a subscription to that connection against a whitelist if the queue isn't in the whitelist it gets binding info etc. and logs the full details. You might be able to do something similar, for example checking connections to see if a certain satellite exists. If each satellite is listening on it's own subscription then you could interrogate the binding which might be a cleaner way of checking whether it exists than checking it's IP is a valid satellite. Another approach might be to take a really QMF like approach and have each satellite act as QMF Agents you could then use the QMF agent discovery to identify which Agents were registered and thus you were able to send messages to. Hope this is some help, best regards, Frase On 19/03/12 16:00, Davide Anastasia wrote: > Hi Fraser, > Thanks a lot for your help! > > Let me try to clarify what I mean for "family". Suppose you have a > component that acts like a router and series of satellite components > (which do pretty much the same job). For some particular reason, I want > to send a certain message to a certain satellite of this router, but I > want to know whether it exists or not. > > Today I came across this: > http://ci.apache.org/projects/qpid/apis/0.10/cpp/html/a00461.html > and I wonder whether this API is currently actively developed or is > deprecated. Examples on the Qpid distribution for Windows use this API > and they seems to be doing exactly what I am looking for. > > Thanks everybody, > Davide > > -----Original Message----- > From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk] > Sent: 16 March 2012 18:33 > To: users@qpid.apache.org > Subject: Re: QMF Tutorial > > Hi Davide, > I'm afraid that I don't quite understand what you're trying to achieve - > you might have to spell it out :-( > > One thing I forgot to add, if you look in the source tree in > qpid/specs/management-schema.xml that will tell you all of the > properties available for all of the broker management objects. > > The connection logger program that I pointed you at just might be able > to give you some pointers, what that does is to list information about > all connections, but it's quite a bit more tricksy than that. I was > interested in identifying whether connections were producers or > consumers. That's actually quite hard.... > > What I did was to get the connection, session and subscription objects > and for each connection work out how many sessions and for each session > work out how many subscriptions - it's hard because sessions are > associated with connections not the other way around and subscriptions > are associated with sessions. It's logical because of the multiplicity, > if it the associations were done the *convenient* way there would be a > 1..* multiplicity but the way it has been implemented in QMF it's a 1..1 > multiplicity. > > Anyway as my connections know the associated subscriptions I can find > the queue reference and from that find bindings - the "-q" option in my > program displays the queues, bindings and exchanges associated with a > connection kind of like a fancy qpid-config -b queues. > > At a guess by "log connections of components owning to a certain > "family" " you might be meaning log connections associated with a > specific subset of bindings - if so you should be able to cannibalise my > connection logger quite easily to do this. > > Hope this makes sense and points you in the right direction. > Best regards, > Frase > > On 16/03/12 17:58, Davide Anastasia wrote: >> Hi Fraser, >> Thanks for your quick reply! >> My primary language is C++ and I use the messaging API and QMF2. >> However I am not scared to prototype something in Python. >> >> What I am trying to do is to log connections of components owning to a >> certain "family", let's say all the components that can serve a >> certain type of request, so that a central "hub" knows how many >> potential consumers are available at every time. I thought it was the >> perfect scenario for a customized heartbeat, but I guess I can achieve >> the same result with the QMF, getting notification on connect and >> disconnect events. >> Am I going in the right direction? Does this make sense to you? >> >> Best, >> Davide >> >> -----Original Message----- >> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk] >> Sent: 16 March 2012 16:49 >> To: users@qpid.apache.org >> Subject: Re: QMF Tutorial >> >> Hi Davide >> What language are you interested in? >> >> I'm afraid QMF is still a bit disjoint you might be aware that there >> are two variants: >> >> QMF1 which uses a compact binary protocol and the QMF1 API - that's >> what the bundled qpid tools such as qpid-config, qpid-stat etc. use. >> That has good python support, I *think* the C++ API works but the Java >> implementation is very broken >> >> QMF2 uses a protocol based on Map messages, that is *relatively* easy >> to drive just by using Map messages because it's primarily in the form >> of key/value pairs. The QMF2 API has a specification hanging off the >> qpid wiki QMF pages There's I believe a prototype python >> implementation and I've written a Java implementation that covers the >> full API there's also a C++ API for QMF2 but unfortunately that bears >> no relation whatsoever to the API specified off the wiki??? >> >> As I say it's rather disjoint :-( >> >> The main QMF page is here: >> https://cwiki.apache.org/qpid/qpid-management-framework.html >> >> A tutorial for the QMF1 python stuff is here: >> https://cwiki.apache.org/qpid/qmf-python-console-tutorial.html >> I recently wrote a connection logger application using this old API >> it's linked to this Jira and might give you some ideas >> https://issues.apache.org/jira/browse/QPID-3869 >> >> The QMF2 documentation lives off here: >> https://cwiki.apache.org/qpid/qmfv2-project-page.html >> >> The Java QMF2 stuff I did is linked off this Jira >> https://issues.apache.org/jira/browse/QPID-3675 >> >> >> HTH >> Frase >> >> >> >> On 16/03/12 16:15, Davide Anastasia wrote: >>> Hi All, >>> >>> Can anybody suggest a good tutorial on QMF? >>> >>> >>> >>> Best, >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For >> additional commands, e-mail: users-help@qpid.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For >> additional commands, e-mail: users-help@qpid.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional > commands, e-mail: users-help@qpid.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org > For additional commands, e-mail: users-help@qpid.apache.org >