On Tue, Apr 2, 2013 at 4:31 AM, Fraser Adams <fraser.ad...@blueyonder.co.uk>wrote:
> > > On 1 Apr 2013, at 22:15, Bill Freeman <ke1g...@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. > Yes. There are session constructor arguments for whether to receive objects, receive events, and receive heartbeats. You can also specify what you are interested in by package or by package and class, and if you specify any some of the flags are forced on, including userbindings, which causes the package/class filtering (which occurs in the console, so this doesn't help with bandwidth). I am using the heartbeat to detect broker failure, with the result that I mark data from that broker as stale (change of color). My current presumption is that agents within a browser can't crash independently. ... > > 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 in the browser is event based. You register a callback for a new message. You send a message either because the user clicked something, or because a timeout expired. So threads aren't forced by WS. > > > > > 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. > I found this (https://cwiki.apache.org/qpid/qmfv2-project-page.html). I probably didn't go here the first time around because the link to it on https://cwiki.apache.org/qpid/qpid-management-framework.html says that it is "for information about the future of QMF", so I figured that it didn't apply yet. > > 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. > > Bill
