In my experience, many organizations that put messaging brokers behind load a balancer eventually take out the load balancer. Generally, less layers is better, and as Tim noted messaging protocols tend to be stateful vs stateless and the client -> server uri's already support failover and retry.

If you want to have a client -> server uri registry, look at the http discovery protocol. You can point your clients to a web page, pass in a parameter and get a uri back-- much simpler to manage vs load balancer solution.


On 9/20/16 12:32 PM, Adam Whitney wrote:
Tim,

Thanks for the quick response.

Regarding setting up and starting a full ActiveMQConnection:
1) No problem on the links, I appreciate the details. I was hoping to have
something a little more lightweight than actually creating a connection and
then closing it ... seems lie creating a new connection every second would
put undo burden on the broker just to probe if the broker is listening on
that port? Is there some other "trick" in openwire to make the probe more
lightweight while still avoiding the error in the broker logs, e.g. just
send something like a WIREFORMAT_INFO request?

Regarding clients reconnecting after broker failover:
2) The F5 would only be used to route the initial connection request ...
after that, my understanding is that as long as clients use the "failover"
protocol when connecting to the VIP, e.g. something like
"failover:(tcp://activemq-vip:61616)", and the broker-side transport
connector has "updateClusterClients" and "rebalanceClusterClients" set to
true, then the broker and client would exchange info about the network
topology and clients would reconnect directly to active brokers should the
initial connection fail.

adam



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/how-to-probe-broker-s-openwire-port-from-an-F5-VIP-tp4716641p4716662.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply via email to