qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: QIP proposal: Easy Broker Info
Date Thu, 13 Jan 2011 16:48:00 GMT
On 01/12/2011 07:43 PM, mick wrote:
> 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.

I understand the specific problem, i.e. the need to be able to get both 
ssl and tcp ports (primarily in testing where you have specified port 0 
for both in order to find a free port). However...

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

...other broker information is available via QMF.

What sorts of information are you thinking about? Anything that is not 
(or would not be) in the management schema? Is this essentially another 
mechanism for simple local access to that data? Do you have any other 
use cases where the usual management mechanism is not a good solution 
and a file based solution would be a significant improvement?

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

I think discovery is a very interesting problem. However I'm not 
convinced that a filesystem based approach is a particularly effective 
solution for that, at least for general use cases.

My concern is that the specific problem of communicating the port used 
is driving a less clearly defined need for an alternative mechanism for 
data retrieval from the broker. I'd like to see a more use cases or 
alternative concrete problems.

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

View raw message