On 03/29/2013 04:35 PM, Bill Freeman wrote:
I'm actually using RH MRG, but that seems to be little different from
upstream Qpid.  I'm certainly seeing v2 qmf queues mentioned in the broker
__dict__.  Please say if I'm making unwarranted assumptions here.  I wanted
my code to be as generic as possible, so I'm trying to avoid depending on
any RH specializations.

There should be no change to the QMF formats or protocols. The only difference as compared with whatever Qpid release on which it is based would be possibly a bug fix or two, but those will in any case be in the Qpid codebase also now.

[...]
That's good to know.  I have been using str(record.objectId()), where
record is the second argument (third if you count self) to an objectProps()
method on a sub-class of qmf.console.Console.  I'm guessing that the final
number in this hyphen separated string of digits, where the last number
tends to be the only multi-digit one, and comes from the objectName field
of qmf.console.ObjectId instances, is a hash of the information that you
mention?
Or am I confusing two separate meanings of "object ID"?
If so, how to I get the ID or which you speak.
If not, doesn't hashing to such a small number have collision potential?

That console API is a bit of a mixture of QMFv1 and QMFv2. I think there is a getObjectId() method, and you can then call asMap() on that to get the v2 form.

Ken, Ted, can either of you correct or confirm on this? (i.e. how to get the v2 style package:class:id identifier for a given QMF object using the old console API.

[...]
I just didn't fine descriptions of what these were in the docs, though I'm
calling functions that require them.  If there's somewhere I should have
looked, I'd appreciate a pointer.

Ah, sorry, the package is org.apache.qpid.broker, the class names are indeed Exchange and Queue.


I think that you're right on track.  I should probably give a bit of
background on my project as a context for understanding my questions.  Or
ignore the rest of this if not interested:

I'm producing a monitoring tool to help spot issues in a federation having
many queues.  This may sound similar to Cumin, but we want displays in
different forms (bar graphs of queue message count compared to some defined
"full" constraint, color changes to attract the administrator's eye to
queues that are "in trouble", popups to allow browsing messages, looking at
bindings, move messages from queue to queue, group queues on the page in
configurable ways...  I looked at modifying cumin, but:
  1. It seems a bit complex - I think that I can write my own faster;
  2. we don't want to use  PostgreSQL (I like pg, but it's not on the
approved tools list);
  3. Cumin has a lot of features we don't need; and
  4. I've caught Cumin missing updates, i.e.;, I spout or drain, sometimes
the queue info shows up within 10 seconds (update/heartbeat rate), but
sometimes it takes another change or two before it shows up.

I have a strawman running just showing queue fullness with a few percent of
full color changes, and now I'm trying to move on to cover the federation.
I wound up with a Cumin like architecture:  A python based qmf console
process that publishes updates to a redis pubsub channel, subscribed to by
a tornado based web server, which pushes them on out to browser based
clients using WebSockets.  There's a custom jQueryUI widget per queue in
the browser that handles display and provides for a context menu.
WebSockets is inherently bi-directional, so I have another redis pubsub
channel for things like commands to move messages, requests to grab a
browse of a queue, get bindings, etc.  I'm using tornado because it
supports WebSockets out of the box, and there's a redis extension for it
using its event loop, so the web server manages to eschew threads.  The
architecture allows for load balancing by having multiple web servers
and/or multiple qmf console processes (though I intend that one qmf console
process be able to handle multiple browser connections, since the
underlying code seems to support that).

Very interesting. Btw, just in case you haven't seen it, Fraser Adams has developed a graphical QMF based console as well which is soon to be added to the repo, but is currently available from https://issues.apache.org/jira/browse/QPID-3675.

It doesn't (yet!) provide the features you mention above, which do sound very nice, but perhaps worth comparing notes at some point.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to