On Tue, Sep 15, 2009 at 4:48 PM, dbczak <z...@dbconcert.com> wrote: > > Yes I'm using failover. The problem is that if I don't set the > maxReconnectAttempts, it waits forever when I call send and the connection > is down. But if I set the maxReconnectAttempts, then after it reaches that > max number of attempts, it never connnects again. Shouldn't I be able to > attempt a send, and continue processing if send fails, and then when the > consumer comes back up, the reconnect should occur and the missed messages > should be processed.
First, let's deal with the connection issue. If the producer is using the failover protocol and the connection fails the failover transport will attempt to automatically reconnect to the broker. There are a few properties to fine-tune the reconnection listed here: http://activemq.apache.org/failover-transport-reference.html I just tested this using the examples that come with ActiveMQ in the example dir. Here are the steps I used: 1) In terminal one, start ActiveMQ using the following command: $ ./bin/activemq 2) In terminal two, cd into the example dir and running the following command: $ ant producer -D"url=failover:(tcp://localhost:61616)" The producer should begin sending messages. By default, it will send 2000 messages. 3) Go to terminal one and kill the broker using ctrl-c 4) Go to terminal two and notice the following error in the producer: [java] 08:58:55 WARN Transport failed to tcp://localhost:61616 , attempting to automatically reconnect due to: java.io.EOFException 5) Go to terminal one and start up ActiveMQ again. 6) Go to terminal two and the producer will output the following message before it begins sending messages again: [java] 08:59:06 INFO Successfully reconnected to tcp://localhost:61616 This is how the failover transport should operate. If you are not seeing the same behavior, then this needs to be addressed to determine why. Second, the MessageProducer.send() method is a synchronous (i.e., blocking) call which requires an active connection to a broker. There is no message buffering capability built in to the message producer to cushion against a broker failure. This is typically where folks use the failover transport. One solution is to use an embedded broker in your application and let it forward messages to the remote broker via network of brokers: http://activemq.apache.org/networks-of-brokers.html By embedding a broker in the Java application and networking it with a remote broker, the ActiveMQ network transport will be used to forward messages between the two brokers. Using this scenario, your application will send locally to the embedded broker using the vm transport (http://activemq.apache.org/vm-transport-reference.html) which is very fast. The messages will be held in that broker until there is demand on the remote broker for those messages (i.e., an active consumer on the same destination on the remote broker). When demand is created for those messages on the remote broker, the local broker will forward them along to be consumed. Bruce -- perl -e 'print unpack("u30","D0G)u8...@4vyy9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" );' ActiveMQ in Action: http://bit.ly/2je6cQ Blog: http://bruceblog.org/ Twitter: http://twitter.com/brucesnyder
