Duplicate Broker ============ Yeah, two connections, duplicate send and receive. One thing to keep in mind with that idea - how will the application handle a broker outage? It won't help to have 2 brokers setup if the producers are blocking on send calls and that blocks the processor generating messages to send to both producers. On the other hand, do you just drop the message for a broker when it is down? I suspect internal queueing would be the desired solution.
Using a message listener, the same recipient of messages could be attached to two consumers; there would likely be concurrency considerations added that way though. Duplicates with JMS =============== JMS does guarantee once-and-only-once delivery of a message to a consumer. However, that's only 100% true when nothing goes wrong in processing. Under the following conditions, a message will be redelivered (there is a redelivery flag in the form of a message property that indicates redelivery): * Non-transacted consumer doesn't acknowledge the message before the connection closes. * Non-transacted consumer's acknowledgement of the message is in-flight back to the broker when the connection drops (i.e. the ack is lost on the transport). * Rollback of a transacted Session. Business Needs =========== The cost of achieving high reliability can be reasonable. For example, sub-secong delivery on the order of 95% of the time (really, this should be measured and extrapolated from the system specs, such as MTBF of hard drives). After that, the costs start to increase exponentially. Consider, for example, the effort of setting up and maintaining the extra brokers, in addition to the extra coding and testing costs. In the redundant-broker-setup, testing would need to include verifying the client operation across the various patterns of broker shutdowns and startup; it would stink to write the solution only to find out in production that the applications stop working whenever one of the two brokers is out of service because the entire processing chain blocks when trying to send to the down broker. Hope this helps! -- View this message in context: http://activemq.2283324.n4.nabble.com/Failover-and-non-persistent-messages-tp4676862p4676981.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
