On Thu, 13 Jan 2011, Steve Huston wrote:
-----Original Message-----
From: Gordon Sim [mailto:g...@redhat.com]
...
My concern is that the specific problem of communicating the
port used
is driving a less clearly defined need for an alternative
mechanism for
data retrieval from the broker. I'd like to see a more use cases or
alternative concrete problems.
That's a nice, succinct way to express my reservations as well.
I see this problem as well. We have one open-ended broker info service
in qmf. We don't need another.
I'm still attracted, however, by the "easy". I'd like to consider
narrowing the scope of the "info" part to make it more palatable.
Currently, it's not easy to recover the configuration of a running broker.
You'd need to recreate the broker's internal configuration routine,
parsing config files and then command-line arguments, to arrive at a
reasonable facsimile, and even then any config that can be altered during
runtime wouldn't be represented.
I think it would be reasonable to write that runtime config out to a file
in the manner that Mick described. It would include:
- auth config
- module dir
- data dir
- port, ssl port
- max connections
It *would not* include:
- process id, memory use, etc. (os services do this)
- queue and exchange definitions (qmf tools do this)
- debug info (logging does this)
This is useful in two primary ways that I can think of: (1) processes that
need this basic info for integration, and (2) recovering debug info when a
broker has a problem.
Qmf can publish all of the same information, but it's imo not as easy to
integrate with. Qmf doesn't, for instance, have a lua client at present.
But any programming environment can read and parse a simple file format.
Second, qmf is not something you can access when a broker is unresponsive.
I'm in total agreement with you and Gordon about needing good, concrete
use cases. Nonetheless, I see potential for utility here.
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
