As I understand it, the text you quoted only applies if replayWhenNoConsumers=false. With replayWhenNoConsumers=true (as you have it), you should get all messages delivered from all brokers that are up, but you still won't get messages from brokers that are down until they come back up. So I think the same conclusion holds, only the text you quoted isn't what proves it.
We made essentially the same decision: our messages are non-persistent for performance reasons, so we can't use any of the three options you mentioned to get master/slave functionality because they all ultimately rely on a persistence store. There was some work done on a share-nothing master-slave capability, but it was buggy and has since been removed. So we're just using pairs of independent brokers, and we've engineered the system to tolerate not getting some messages (or getting them late/out-of-order) when a broker failure occurs. On Fri, Nov 7, 2014 at 3:20 AM, jeremy11 <liav.el...@gmail.com> wrote: > Hi, > > I also tested durable subscriber on a network of 2 brokers and you are > correct this case can also happen, from the documents on durable > subscription: "However, if the subscriber disconnects and reconnects to > broker A, any messages sent by P while the subscriber was away will be > stuck > on B until the subscriber reconnects to B" (from > > http://activemq.apache.org/how-do-i-use-durable-subscribers-in-a-network-of-brokers.html > ). > so going to master/slave solution seems to be one solution but in this case > you should have: > 1. shared file system or, > 2. shared db or, > 3. use Replicated LevelDB Store - the documentation says it is recommended > to use at least 3 replica nodes > > I can't assume I will have shared file system or shared db in production > and > I dont want more than 2 brokers so if I can leave with the fact that if the > subscriber goes down and goes up again it should make sync (with db/rest > server etc) and only then reconnects to the broker I think the solution of > simple topic might be enough with the failover of consumer and producer to > each of the brokers to ensure that if one broker goes down the consumer and > producer will automatically connects to the second broker. > > thanks again Tim > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Network-of-brokers-as-a-cluster-tp4687028p4687051.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
