On 1 Apr 2013, at 19:56, Bill Freeman <[email protected]> wrote:
> > > 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). > That's definitely a QMF1 API that you are using then, there are actually two python QMF1 APIs one uses getObjects() calls and the other has a notification type API. The 10 second interval can be charged by a broker switch BTW I can't recall exactly what it is off the top of my head, but if you do qpidd -h it should hopefully be obvious. As an aside you mentioned previously about cumin "missing" updates, possibly that's true, but it shouldn't really matter and your application should probably be designed to be tolerant of this sort of thing - the updates of things like queueDepth, msgEnqueue, msgDequeue etc. are all "incremental" so there's no concept of "resetting" values a client has to track an initial value and deltas, it's worth pointing out though that timestamps are sent with each update, so if an update has been delayed in transit you can use the update time stamp to know the timestamp from the broker's perspective. > > > 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). It has been a while since I looked at the guts of QMF2 ObjectIds as I say I tend to treat them as opaque. I think that Gordon's previous comments about V2 OIDs looked about right, but I'd need to have a proper look. As he said V1 and V2 OIDs are rather different. In V2 there's an epoch value that changes across broker restarts, I think that only applies to the Agent name and not the OIDs, but it has been a while, I'll have a proper look when I get IT back if you can bear with me. You mention being consistent across broker restarts, I'm assuming you are talking about persistent queues? Clearly non-persistent queues will be different objects. I'm not sure whether the broker treats recreated persistent queues as the same objects each restart, possibly but I can't be sure, it might not even be the right thing to do that, if you did the same thing with say an in memory object reference they would definitely be at different addresses and TBH that's usually how I view ObjectIds - as a way of describing an address at a point in time. I'll need to take a prober look to ascertain the current truth though. > > > 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. Fair enough if you are more familiar with python, but I really really would recommend moving away from QMF1 and perhaps use the lib tool API Gordon mentioned earlier. As I mentioned before management is likely to be in for something of a reshuffle, I think it's likely that there will be attempts to make transitioning from QMF2 as easy as possible, but that probably won't hold for QMF1. > And Rest doesn't sound promising for getting updates pushed to > me. > So you may be right, though QMF2 has a getWorkItem() call which can be blocking, that is used in QMF2 in place of a pure asynchronous model as there was talk in the spec of avoiding threading issues. I implemented this in REST via a long-polling call which works pretty well, my GUI actually works by getting notified on heartbeats and other asynchronous events such as queueDeclare etc. when triggered it then does a synchronous getObjects() call - via REST which ultimately calls my Java getObjects(). I won't get into the relative pros and cons of long-polling versus WebSockets, I generally agree that the latter is the way to go, but I needed wide browser support and TBH I need to get a bit more up to speed on WebSockets, it's definitely on my list of things to do, but the current approach works pretty well, and is arguably a pretty good mapping to the underlying API call. > >> 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. These support QMF1 and QMF2, but from a client perspective I'd really recommend avoiding QMF1 if you possibly can. The data push stuff is supported in both QMF1 and QMF2 formats. The QMF2 API allows a type of query subscription, but the C++ broker doesn't actually support this :-( I actually managed to fake this in my Java implementation by doing a data subscription and filtering on the client side to implement the query API. That said it might have been overkill, I went to town implementing the full QMF2 API, but it hasn't really taken off and the python lib tools stuff, although it implements the QMF2 protocol doesn't really implement a documented API. The lack of standardisation of QMF2 and the hitherto lack of support on the Java broker is one of the things driving the moves to try and create a properly standardised AMQP 1.0 management protocol and API. I've been working on QMF2 support for the Java broker and it's something of a mission of mine to try and improve the overall cohesion of AMQP management, that was one of the key drivers behind the GUI I put together and the work I'm starting on the Java broker. I'll try to give a bit more detail later in the week on some of this, some of it will require me to have a bit of an eyeball at some code. Frase --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
