qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Stitcher <astitc...@redhat.com>
Subject Re: QIP proposal: Easy Broker Info
Date Wed, 12 Jan 2011 21:00:36 GMT
On Wed, 2011-01-12 at 15:31 -0500, Justin Ross wrote:
> ...
> > Summary
> >
> >        Brokers write simple name-value pairs, one to a line, into PID
> >        files in /var/run/qpid. The names are tree-structured. Files are
> >        updated periodically, and taken down when broker shuts down
> >        normally. This allows easy discovery of broker info by any
> >        script or program.
> 
> I might consider dropping the tree-structured names part.  Based on my 
> experience with java properties files, I find people tend to be confused 
> as to whether ".", for instance, is a word separator or a parent-child 
> operator.  The result is a big mess.
> 
> I see two options: decide up front that data with an implicit tree 
> structure is not necessary and remove the language about trees, or switch 
> to a format that truly supports nested data (json, yaml, etc.).

I'm not wholly convinced by Justin's argument, but you must specify the
file format including the separation of the hierarchy - Justin has
assumed the separator is "." which is consistent with many other config
files. However Mick seems to have used "_" as his separator.

I note that you could have flat name space that looks like a hierarchy
merely by allowing a de facto separator character to occur in the names.

> ...
> > Implementation Notes
> >
> >        I think this is dead easy, in its first impl. make a class
> >        called something like ... infoPublisher ... or something. Make a
> >        public instance of it in the Broker. Anything in the code that
> >        can reach the Broker can call broker->infoPublisher ( name,
> >        value ); And that pair will get written out to the appropriate
> >        file. You can make it either replace any previous instance of
> >        that attr-value pair in the file, or just append this latest
> >        line to the end of the file. This code would be in
> >        cpp/src/qpid/broker . /em>
> 
> I find the alternative append behavior surprising.  I tend to think it 
> should be simpler: there's a map in memory, and sometimes it gets written 
> to disk.
> 

I find the append only behaviour fairly reasonable - it would act as a
journal. It's easy to implement by the broker - just write out a single
new line whenever something changes. A reading program would have to
read every line and allow subsequent lines to overwrite existing values.

As Justin notes if you write out the whole map to some trigger than you
have to figure out what that trigger might be.

Andrew



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


Mime
View raw message