Sorry for discussing something slightly off topic, but I thought it might be
worth mentioning it here.
There was an idea floating around (I believe it was Rafi who initiated it)
about having live and passive backups for a broker.
The current clustering solution in 'some ways' provide the live backup in
that a client can connect to an "identical" copy and resume operations.
However micks idea could potentially be useful in providing a passive
backup.
Following are some benefits that can be derived as a result of such a
feature.
1.) Restart a broker with the last-known-state before the crash.
There are several customers that are running Qpid in non-clustered
environments. In such cases the above might be useful.
2.) Examine the state of the broker in a live site (queue depths..etc)
before it crashed for investigative purposes.
3.) An extremely handy debug tool during testing and pre production runs.
For both item (2) & (3) the journalling of the broker state could be very
useful as it provides time based snapshots of events/state leading up to the
crash.
Obviously this does come at a cost as IO operations are not cheap, but if
enough computing power can be spared for this service running on it's own
can be a very useful addition to qpid users.
Regards,
Rajith
On Wed, Jan 12, 2011 at 2:43 PM, mick <[email protected]> wrote:
> 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
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
