On 01/13/2011 06:00 PM, Justin Ross wrote:
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,
Other than the ports (which I think is the local discovery rafi
highlights, and is actually the primary motivator for the proposal I
believe), what other sorts of integration might processes need to do?
and (2) recovering debug info when a broker has a problem.
I can see the argument there certainly. Not totally convinced that in
practice this is significantly better than getting the conf file and
knowing how the process was started, but it would be trivial to log out
the full config to a file. Logging it to the main log file would also be
useful, but using a separate file has the advantage of being accessible
even if the log files are rotated and truncated.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
