> We are going to use the active/passive mode of operation along with Berkeley DB to support our high availability design
I'm not aware if the combination of C++ client/Java Broker in HA mode has been tested. All of the automated testing is Java Client/Java Broker. That said, I'm not aware of a reason why it would fail. Please let us know how you get on. > "The automatic failover feature is available only for AMQP connections from the Java client. Management connections (JMX) do not current offer this feature". Is this only when a broker list is passed during the connection process? Yes, that's correct. This refers to the in-built faiover features of the client, i.e. the broker list passed through the connection url. The footnote merely points out that if a (Java) application also made use of JMX (or REST for that matter) to perform Management operations on the Java Broker, these connections would not failover. May I also take this opportunity to mention that we are currently enhancing the HA features of the Java Broker. It will support clusters formed of greater than two nodes, and the cluster management/monitoring will be better integrated into the Web Management Console. On 2 July 2013 09:17, Gordon Sim <[email protected]> wrote: > On 07/01/2013 11:02 PM, jbelch wrote: > >> Also, is there a good >> example of C++ client code that would automatically reconnect? We >> currently >> have logic to catch exceptions and reconnect based on these exceptions, >> but >> we were thinking it would be cleaner if we could use the reconnect logic >> that Qpid supports. >> > > There isn't a specific example, but there is not much to it. You just need > to turn on the reconnect option. You can try it out with the spout and > drain examples. E.g. > > spout --connection-options '{reconnect:True}' amq.fanout > > Then b0ounce the broker and watch it reconnect. > > Other connection options to more finely control the reconnect logic are: > > * reconnect_timeout: seconds (give up and report failure after specified > time) > > * reconnect_limit: n (give up and report failure after specified number > of attempts) > > * reconnect_interval_min: seconds (initial delay between failed > reconnection attempts) > > * reconnect_interval_max: seconds (maximum delay between failed > reconnection attempts) > > * reconnect_interval: shorthand for setting the same > reconnect_interval_min/max > > * reconnect_urls: list of alternate urls to try when connecting > > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > >
