Hi,
There are a couple of directories related to QMF - here's a quick summary:
qpid/cpp/src/qpid/management - this is the implementation of the QMF agent in
the QPID broker itself. It is used to manage the broker. This supports QMFv2
format object queries and method calls, but schema data is still exposed in the
QMFv1 binary packed format. You want to look at this code when you're trying
to manage the broker.
qpid/cpp/src/qpid/agent - generic QMF agent library for use with non-broker
applications. This is the code you'll use if you are creating an application
that will act as an "agent" (that is, a QMF-managed entity). You embed this
code into your application, and can then use QMF to manage it. This is -not-
used to manage the qpid broker (that stuffs in ../management).
qpid/cpp/src/qpid/console - generic code to build a management application to
talk QMF to an agent.
qpid/cpp/include/qmf/ - the include files (api) for console/agent libraries. We
also generate wrapper api's for various languages from these headers (python,
ruby).
> On a related note could anyone let me know how to query for Agents. My basic
> Console class currently only talks to the broker Agent via
> "qmf.default.direct/broker". I'm guessing querying for agents will be by
> sending a message to a topic/subject - could someone suggest the structure
> of the message and Address.
Depends on which version agent (QMFv1 or QMFv2) you want.
The broker agent maintains a list of all known v1 agents that are connected to
it. You can query for them like you'd query for any other object on the
broker, except you'd need to specify "agent" as the "_class_name" value in the
"_schema_id" map.
"_schema_id": {"_class_name": "agent"}
That would return all known v1 agents.
v2 is a bit more difficult, and that's where the library code comes in handy.
Turns out that having the broker maintain the list of all known agents resulted
in a scalability bottleneck. As an alternative, v2 requires consoles to
register for "heartbeat" messages from agents, rather than querying the broker.
The library code maintains a database of agents by listening for these
heartbeat messages, timing out old heartbeats, etc.
A console can request that all agents identify themselves manually - this is
done by sending a "broadcast" "_agent_locate_request" message from the console.
To do this, send a QMFv2 message to
"qmf.default.topic/console.request.agent_locate"
with {'qmf.opcode':'_agent_locate_request'}.
Agent's will reply with a heartbeat message - see agent/ManagementAgentImpl.cpp
for the format of a heartbeat message.
A good example of a QMFv2 console - and some code that highlights all of the
console logic above - can be seen in the python QMF console:
qpid/extras/qmf/src/py/qmf/console.py.
-K
----- Original Message -----
> On 07/17/2011 10:37 AM, fadams wrote:
> > Hi again Gordon,
> > I've taken to looking through the C++ broker code to figure some of
> > this out
> > and I'm afraid it's making my head EXPLODE :-)
> >
> > So I've found ./cpp/src/qpid/management/ManagementAgent.cpp and the
> > method
> > "handleGetQueryLH" does indeed say "Currently we only support OBJECT
> > queries".
> >
> > handleGetQueryLH seems to be dispatched from dispatchAgentCommandLH
> > which in
> > turn is called from dispatchCommand which seems to be called from
> > specialised Direct& Topic Exchanges
> >
> > So far so good, but I also found
> > ./cpp/src/qpid/agent/ManagementAgentImpl.cpp - looking at the
> > headers this
> > *appears* to inherit from ManagementAgent - though I'm not clear
> > what
> > behaviours it inherits..
> >
> > This has a method handleGetQuery which has a lot of similarities
> > with
> > handleGetQueryLH (though this seems to support "SCHEMA_ID" at least
> > partially) this seems to be dispatched from a received method,
> > though I
> > couldn't figure out what calls that.
> >
> >
> > So what's the relationship between ManagementAgent and
> > ManagementAgentImpl?
> > I grepped the code base and ManagementAgentImpl seems to be called
> > by as a
> > Singleton but the getInstance doesn't seem to be called anywhere
> > except some
> > testagent.cpp.
> >
> > Have I missed something or should I just focus on the
> > ./src/qpid/management
> > directory...
>
> I'm not the expert on the QMF related code, however two points will
> probably help explain the bigger picture a little.
>
> First, there are two versions of the QMF protocol. Version 1 had a
> custom message encoding scheme and really required that you use it
> through an API. Version 2 was designed to be easier to use as a
> messaging protocol in its own right, with map- and list- encodings for
> messages and simpler interactions.
>
> The second point is that the QMF work has had a broader goal in mind
> than smply managing the broker. It was designed to be able to be a
> general management infrastructure. Therefore it is possible to
> implement
> arbitrary management agents, each with their own schemas and interact
> with them using QMF layered on AMQP.
>
> I believe the qpid::agent code is an old API for QMFv1 based
> management
> agents (apart from the broker),but perhaps Ted or Ken can correct me
> on
> this.
>
> At present I believe that the qpid::management code is essentially the
> brokers own internal management agent. However in the QMFv1 protocol
> the
> broker was a more explicit intermediary in all agent communications so
> the distinction there is a little blurred. The code also has two
> parallel implementations for the two different versions and as you
> noted, the second version seems not yet to support querying of the
> schema.
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
