qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: QIP proposal: Easy Broker Info
Date Mon, 17 Jan 2011 14:57:14 GMT
On 01/13/2011 01:00 PM, Justin Ross wrote:
> On Thu, 13 Jan 2011, Steve Huston wrote:
>>> -----Original Message-----
>>> From: Gordon Sim [mailto:gsim@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 suggest the following, which I've seen  used to good effect in previous projects:

   --dump-config FILE   Instruct the broker to write it's configuration to FILE 
(default none)

This would write a file in the known qpid-config file format with the "live" 
values of config items like port or ssl-port, or other computed config values.

When config can be picked up from multiple sources, such a tool is useful to be 
sure what actually got configured. It uses existing known file formats. It 
clearly scopes the use of the tool to checking initial configuration, it doesn't 
want to become a replacement for management.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message