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:[email protected] > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
