qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mick <mgoul...@redhat.com>
Subject Re: QIP proposal: Easy Broker Info
Date Thu, 13 Jan 2011 15:32:51 GMT
On Wed, 2011-01-12 at 16:00 -0500, Andrew Stitcher wrote:
> 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.
> 

My intention was as Andrew says -- to have a flat namespace that can
look tree-formed if you wish, by including an underscore as a legal
character.   It seems really nice to do it this way for grepping
purposes, so i can get all of a category of info by grepping for a
leading substring.

You know -- the problem of using real nesting comes up a lot -- but we
do not have any tool that is nearly as ubiquitous as grep that can deal
with simple markup.

Hey, wait -- should I just write it out as a Python tree ( nested
lists ).  Would that make it easy to extract nodes of the tree?


> > ...
> > > 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.

i'm happy to do it either way -- i was initially thinking of
a /proc-like behavior, where it gets updated whenever something changes.

this discussion makes me realize that there is no point in making this a
sort of logging-lite facility -- we already have logging -- in fact,
this facility would tell you where the log for the(each) broker is being
stored.  

I will have to lock the file when i write to it anyway, since different
threads may all want to write info.

what i think would be nicest is just an image in memory as Jross said,
it gets written out to a (locked) file occasionally -- the trigger is
simply when-something-changes.

i think this should remain a simple-as-possible facility that gives sort
of vital broker info that many processes or scripts would need --
including a pointer to the logfile, where you can find other stuff.  (if
it's being logged).

oh, you know -- current log level would be shown by this facility.
current number of connections.   ports&transports.  etc. 

> 
> 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
> 



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


Mime
View raw message