On Tue, 2011-01-18 at 11:13 -0500, Alan Conway wrote: > > I don't see this as something that applies in deployment. You're never > going to > deploy brokers without knowing in advance what port they're using, the > broker's > host:port are the fundamental location information that clients have > to know to > connect. I don't see any non-test use case where a client knows the > broker's PID > but not the port.
OK, I guess I was trying to sneak in a Discovery use-case, at least local discovery, into this. The point with that was that -- even if you know the broker ports ( and whatever else similar ) in advance, how do you communicate that knowledge to apps that start up after the brokers are running? We should have a standard way of communicating that knowledge. *** I must admit, though, that local-discovery would probably best be done as a special case of Global Discovery, and that the final-config-echoing solution you suggested here sounds the like the best bang for the least buck for this limited "Easy Broker Info" idea. *** When we do the (separate) Discovery feature it should include not only brokers/ports/transports but also available clusters & something about federations. i.e. an app should be able to wake up knowing only the name of a cluster it wants to connect to, and be able to easily discover the ssl and tcp ports of that cluster. Also it seems cleanest to have a solution that allows the ports associated with clusters/feds to change over time. New brokers get added or subtracted. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
