Index
Easy Broker Info Service
Status
Draft
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.
Problem
I wrote a script in which I needed to know the port that my
broker was listening on for both TCP, and for SSL. There was no
way to get this info. Right now, we use a mechanism where the
broker writes the port number to stdout that it has chosen
( when you use --port 0 ). You can tell it to report on a
different transport's port (i.e. SSL ) by using the
"--transport" flag. But what if you want to know several
different pieces of info about the broker? What if you are not
the script that started it, but are just some other program or
script that is coming late to the party? There should be one
central, easy way to discover all running brokers, discover
which of them are clustered, etc. What ports they are listening
on. Maybe even info that gets updated periodically like health
information, throughput, etc.
Solution
Brokers write information about themselves to files in a
well-known directory ( i.e. /var/run/qpid ). This allows any
running program or script to easily discover what brokers are
running, what ports they are listening to for which transports,
and any other information that the brokers want to share. This
is strictly broker-based, and works whether or not management is
enabled. Brokers only write the info, and non-brokers only read
it. The info is in a simple, easily grepped name-value format,
whose names are tree-structured. For example:
"transports_tcp_port 6666". There is a single name-value pair
per line.
Rationale
I think this is the simplest possible solution for this problem.
I want something that is strictly broker-based, i.e. not
dependent on management, language-neutral, OS-neutral, easily
greppable. At first I thought of /proc, but that's too hinky.
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>
Consequences
There are consequences in the following areas:
* Documentation: We would need a list of all the
attributes names, and the formats of their values (int,
string)
Contributor-in-Charge
Mick Goulish
[email protected]
Contributors
Mick Goulish [email protected]
Version
1.0
