qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Questions from a novice
Date Mon, 01 Apr 2013 09:03:05 GMT
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message