qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Kennedy <andrewinternatio...@gmail.com>
Subject Re: QIP proposal: Easy Broker Info
Date Thu, 13 Jan 2011 21:24:40 GMT
On 13 Jan 2011, at 18:00, 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 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 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-subscribe@qpid.apache.org

View raw message