qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <jr...@redhat.com>
Subject RE: QIP proposal: Easy Broker Info
Date Thu, 13 Jan 2011 18:00:47 GMT
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.


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

View raw message