qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Questions from a novice
Date Tue, 02 Apr 2013 08:31:00 GMT


On 1 Apr 2013, at 22:15, Bill Freeman <ke1g.nh@gmail.com> wrote:
> 
> I realize that the final numbers come out the same.  But this is to be an
> interactive tool, used by people who are panicking because some queue seems
> wedged.  So if they command a change, I'd really like to show them a
> result.  Within 10 seconds seems fine.  Not until the next time something
> happens to the queue probably is not.
> 
The data push stuff also allows receipt of heartbeats messages, TBH I don't use the V1 APIs
much but I think that you can specify what you receive from the broker. If you are only specifying
object updates you will only get notified when objects have changed. If you want a regular
prod even if nothing has actually changed you could possibly use the heartbeat for this.

> 
> 
> I personally don't care whether I use object IDs or not.  In fact, I'd
> rather use the queue name or exchange name, etc.  That's the real problem
> for me with the V1 interface.  I get two separate callbacks.  One has
> properties (and I think that I only get this once per object, and I've only
> looked at queues so far), and thus has the name.  The other callback has
> statistics, but no properties, so I can't use the name property to look up
> the (local cached) object for which this is a statistics update.  So I'm
> using str(xxx.getObjectId()) to match them up*.
That looks about right, I think the idea is to minimise bandwidth. As you say what apps normally
do is to receive the property update and use the OIDs retrieved from that as a key to match
subsequent statistics pushes, if you look at qpid-queue-stat that behaves like this - certainly
for older qpid versions, I've not looked recently though.

I have personally found that API to be quite fiddly when it comes to tracking changes, you
end up having to be pretty careful.


> 
> [* I think that some of the code in qmf.console has some dictionaries
> indexed by ObjectId instances themselves, rather than their string values,
> which I'm not sure is wise.  But I'd have to go back and look again to be
> sure. ]
> 
I think that's true I'm pretty certain that that's the case in qpid-queue-stat, I suspect
that there's some syntactic sugar under the hood which makes indexing by the ObjectId OK.

> 
> We python folks have a particularly high motivation to avoid threads.
> Tornado's event loop model (something like Twisted, but different) is
> pretty slick on OSes that support epoll or select.
I've no issue with that, though JavaScript has even less thread support and the Rest stuff
I've described works really nicely via AJAX.

> 
> WebSockets is pretty nifty.  Comet done right.  Pretty easy to use.  An
> awful lot of browsers support it now.  There is a JavaScript library,
> socksjs (apparently more than one: socket.io), that will use it if it's
> there and emulate it if it's not, using long poll or whatever old Comet
> technology works,
Yeah I realise that, it's mainly about familiarity - or lack thereof, it is on my list of
things to do to get up to speed with WebSockets. One of the things being talked about in the
qpid AMQP 1.0 discussions is having the brokers support a WebSocket transport as well as a
TCP one and provide a pure JavaScript AMQP 1.0 implementation, that sounds pretty cool.


> even being able to fall back to polling with GETs.  Of
> course you have to code your server to handle the GETs if you want to fall
> back that far.  That's not to say that I've used it.  Plain WebSockets has
> been working in my test environment: Chrome, recent Firefoxes, even the
> most recent IEs.
> 
It is definitely the way of the future. I need to support IE8 so I'd need the polling fallbacks.
Also as I say the getWorkItems() API call actually maps pretty well to a REST long-poll so
I wasn't beating myself up too much, most of the QMF2 API is synchronous really.

> 
> By which you mean documented in the XML?  Or is there a documentation link
> that I haven't found?  (I've read so much stuff over the last couple of
> months that my head is still spinning pretty faxt.)
The XML stuff covers the management schema so is very useful, but I was talking about the
QMF2 protocol and API documentation. I don't have the URL handy but if you go to the qpid
home page then navigate to the wiki there's a link off that to QMF and from there there's
links to the QMF2 project pages with links to the protocol and API.

When I get back to my main PC I should be able to help you get started with a subscription
to the QMF2 data and heartbeat push. As Ken suggested I don't think that there's any API support
for this in the qpidlibtools python stuff, but it is mostly a subscription to qmf.default.topic/data.ind.*
with the data coming back as Map messages, that might be enough for your needs.

> 
> Cohesion would be great.
Oh yes, it's a bit of a soap box of mine :-)

Regards,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message