I'm very grateful for Dejan's input on the thread http://activemq.2283324.n4.nabble.com/broker-config-if-destination-may-be-down-td3086163.html
However I feel like perhaps I'm hitting this issue because of some fundamental problem with my approach. What I am trying to do is actually easy to describe, especially when you don't take security or failover into account. 1. Say there are 2 servers, A and B. 2. There is only one type of message, and each server both sends and receives it. 3. Sometimes A or B is down, and sometimes one server is started and expected to run without the other ever starting. No server/broker is _always_ up. 4. The sending process shouldn't care if the remote server is up (messages should cue up). 5. The receiving process shouldn't care if the remote server is up, it just waits for data. 6. It's okay if we lose messages if too many would cue up, etc. The important thing is that we re-establish the message flow between A and B when they are both available. Currently I have one bridged broker on each server, and our sending and receiving processes communicate with it using a vm connection. This setup works for most cases including transient network outages and even bouncing one of the servers, but it does NOT work if the remote server is unavailable at startup time*. (* possibly because I use a failover transport, which is probably required) What I'd love to hear is how other's might approach this problem? Am I over or under engineering this? Should I have 2 brokers on each server? -- View this message in context: http://activemq.2283324.n4.nabble.com/Perhaps-I-m-just-approaching-this-the-wrong-way-tp3089461p3089461.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
