Hi Keith,
I'm afraid I've got no familiarity with the Java broker other than
knowing that it exists, but the stuff you mentioned below (the JMX and
RESTful API interest me).
You may or may not be aware of this, but I recently released a pretty
comprehensive GUI for Qpid, well as it happens really it's a GUI for the
C++ broker that makes use of QMF. The architecture for this comprises a
Java Implementation of the QMF2 API, this is then exposed via a RESTful
implementation of the QMF2 API, which in turn is used by a JavaScript
implementation of the QMF2 API running on the browser.
The RESTful API allows QMF connections to multiple brokers by allowing
users to PUT Qpid Connections.
One of the things that I was toying with was the idea of extending this
to the Java broker, though it sounds like there's a degree of overlap
with what you've described here.
Do you know how closely (or otherwise) the Java broker JMX or REST
objects mirror the QMF Management Objects in the C++ broker? With QMF
there is access to Connection, Session, Subscription, Queue, Exchange,
Binding and much more sounds like this is available in JMX but not via
the Java broker REST API???
Could you point me at the documentation for the JMX & REST APIs? Is
there example code?
Is the Java broker REST API backed by the JMX Management Objects or is
that completely separate?
How are things like Queues, Exchanges, Bindings etc. added it that via
JMX methods or something else - in the C++ broker it's via QMF methods.
In an "ideal world" I'd really like to do some harmonisation and extend
my GUI to talk to C++ and Java brokers with as much consistency as
possible. I've no idea if that's even possible given the capabilities of
the Java Management Object or the differences between QMF and JMX.
Does this seem useful or just crazy?
Frase
On 10/02/13 12:58, Keith W wrote:
Hello Peter
Qpid-cli was removed some time ago (by QPID-3260). At the point of
its removal, it had received no maintenance for a number of years and
has been omitted since 0.6 owing to problems affecting its release
artefacts. I doubt resurrection would be straightforward and I would
encourage more discussion on this list prior to any effort expended in
that direction.
The Java Broker has two management interfaces: JMX interface and a
web-management interface (which is backed by a RESTful API) both of
these interfaces could be used in a programmatic fashion from
monitoring scripts. The JMX interface exposes the connections to the
Broker via org.apache.qpid.management.common.mbeans.ManagedConnection.
Sessions within those connections are exposed by the
ManagedConnection#channels() operation. Connections/sessions are not
yet exposed via the REST interface.
Kind regards, Keith.
On 8 February 2013 21:00, Richard Peter <[email protected]> wrote:
Lahiru,
Thanks for the quick response. That would be soon enough for my time
tables. I can continue development/testing without the CLI for now. I
would need something within a month for me to integrate it with our current
monitoring scripts. I'm considering expanding on the current JMX management
to allow monitoring of sessions. This was available on the python
management side and we used it for traceability to track down specific
connections to queues/consumers and I would need to keep this functionality.
On 02/08/2013 02:22 PM, Lahiru Gunathilake wrote:
Hi Richard,
How urgent is this ? I can certainly have a look in to this week after
next
week, and fix the CLI for Java broker.
Regards
Lahiru
On Fri, Feb 8, 2013 at 3:00 PM, Richard
Peter<[email protected]>wrote:
We are in the process of switching from the C++ broker to the java
broker.
Is there no CLI replacement for qpid-stat for the java broker? Found
the
qpid-cli from 2008, but according to posts from Robbie in 2009 it hasn't
been maintained. We use qpid-stat extensively for remote monitoring of
remote qpid brokers.
Thanks,
Richard Peter
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
[email protected].**org<[email protected]>
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
