On 13 Jan 2011, at 18:00, Justin Ross wrote:
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.
I would suggest a nice pluggable architecture. There would be a
broker info provider class, just like you suggested, which would be
feeding into a one or many publisheres. These could be, for example:
* A '/var/lib/qpid/' filesystem driver on Linux
* A 'C:\Documents and Settings\Qpid User\Local Settings\Application
Data\' filesystem driver for Windows
* A Registry driver on Windows
* An Active Directory driver on Windows Server
* an SNMP MIB generator for systems with an SNMP agent
* A JMX driver on the Java broker
* A QMF driver for both Java and C++ brokers
You could include a lot of information in the provider's dump and the
publisher plugins will decide what information to filter out of this
and select and how (and how often) to present it.
That gives you a lot of flexibility and extends your use cases into
things like automated broker discovery and enterprise auditing and
management tools. Easy is good, but single purpose features are dead
ends. We should be looking at creating a full-on best-of-breed
enterprise messaging system that can *really* compete with all the
commercial entities out there, and we need many of these features,
like active discovery, for that.
Andrew.
--
-- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
-- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
