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-subscr...@qpid.apache.org
