I don't think this will address Mark's question (but Mark, please correct if I'm wrong).
If I understand him correctly, he wants the client to know when Broker X is no longer available, and at that time, kill its current connection and then keep trying to automatically re-connect to Broker X until it is back online and available. The failover transport is primarily used to connect to a different broker (e.g. Broker Y) in the event that the currently connected broker fails, no? Also, could the behavior he is seeing be due to TCP socket timeout? I have experienced problems with uncleanly shut-down sockets in the past and due to TCP keepalive, the client sometimes won't know the connection is dead for quite a while (e.g. default on Linux is I think 2 hours). The only way to avoid this particular problem is to use a heartbeat mechanism. Does ActiveMQ address this concern? I too would like to know how to auto-reconnect my consumers to the same broker as well, and here's why: Due to firewall issues, we have (potentially many) consumers that will use the HTTPS transport to connect to the broker through a load balancer. We do failover swapping, restarts and such behind the load balancer, so the client doesn't need to be aware of multiple transport URLs. They will only ever need a single HTTPS transport URL. As such, how do I ensure that if a consumer loses a connection to the broker, they can continually try to auto-reconnect to the same transport URL? Thanks, Les On Sun, Jun 2, 2013 at 6:50 PM, SuoNayi <suonayi2...@163.com> wrote: > Just use the failover transport instead of your plain tcp transport, > it can reconnect to the broker transparently and it will replay > producers/consumers, the connection and pending transactions > when reconnection is successful. > http://activemq.apache.org/failover-transport-reference.html > > > At 2013-06-02 20:37:36,fenbers <mark.fenb...@noaa.gov> wrote: >>If ActiveMQ is restarted, we find that our producers and our consumers have >>to be shut down and relaunched in order to reestablish the connection with >>ActiveMQ. This is a royal pain! However, a producer will throw an >>exception whenever it tries to send a message through a lost connection, and >>so I catch the exception where I can close the connection and reopen it. >>Thus, my producers are able to reconnect automatically in the event ActiveMQ >>is restarted. >> >>But with a consumer, no exception is thrown as it waits for message >>notifications. It simply waits eternally for a notification that never >>happens once a connection with ActiveMQ is lost. So what is the recommended >>approach for a consumer to check for a disconnection?? >>Mark >> >> >> >>-- >>View this message in context: >>http://activemq.2283324.n4.nabble.com/How-to-detect-a-consumer-s-lost-connection-tp4667733.html >>Sent from the ActiveMQ - User mailing list archive at Nabble.com.
