activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From logosdev <>
Subject Perhaps I'm just approaching this the wrong way
Date Wed, 15 Dec 2010 17:32:42 GMT

I'm very grateful for Dejan's input on the thread

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:
Sent from the ActiveMQ - User mailing list archive at

View raw message