I see. If you used fuse fabric to manage the brokers, zookeeper would keep info about which is master/slave and you could set a watch on those nodes and be updated when something causes the nodes to get updated.
Out of the box, without the help of a distributed cluster coordinator, not sure how many options you have. poor man's approach without fuse fabric could be to deploy a camel route along with each broker that publishes to zookeeper the state of the broker (is master? and some host/port info), and then if your monitoring app loses jmx connection, it can cycle through the nodes in zookeeper to find out which is the correct next master. The way the webconsole currently does it is by knowing about the master/slave ahead of time. but if your slaves in the cluster can be dynamic, would need to rely on some other way to figure them out. Additionally, you could try to use an HTTP discovery agent to publish a broker's transports. You can use that to try to determine what the host name is and just assume default ports. Take a look at org.apache.activemq.transport.discovery.http.DiscoveryRegistryServlet which would need to be exposed... and the transports in your broker would need to publish to the discovery url: http://activemq.apache.org/discovery-transport-reference.html Those are my thoughts :) others might chime in... On Wed, Aug 14, 2013 at 10:11 AM, deepak_a <angesh...@gmail.com> wrote: > Hi, > > May be I am not explaining properly. > > My app connects to the Master or Slave based on the HostName/IP-Address. > > Prior to clustering my app always connected to localhost/default-JMX-port > DEFAULT_MESSAGE_BUS_JMX_HOST = "localhost"; > DEFAULT_MESSAGE_BUS_JMX_PORT = 19999; > > Now with clustering my slave will become Primary and vice versa. > And as it stands - my app does not know which node's JMX to connect to. > > *Note*: HA/HS itself is fine (I am able to get messages routed across > properly if master goes down), i.e. my ejb's have a fail-over set up, so > they connect to the right node/broker. i.e. > failover:(tcp://A.B.C.D:61616,tcp://E.F.G.H:61617)?randomize=false > > regards > D > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/regarding-use-of-Advisory-messages-for-node-failure-in-a-Cluster-tp4670361p4670382.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta