Each message exists on one and only one node at a time in a network of brokers, and is forwarded from broker to broker based on demand. If you're looking for replication, for example to protect you from messages being unavailable if a broker goes offline, a NoB won't give you that.
And replicated LevelDB is only applicable in a master-slave pair, where only one node at a time is accepting connections, which doesn't sound like what you want either. It sounds like what you want is clustered operation, and 5.x doesn't support that. But Artemis does, if you feel up for following the suggestions Jonathan offered to give you for how to integrate it into TomEE. Tim On Jan 26, 2018 10:08 AM, "COURTAULT Francois" <Francois.Courtault@gemalto. com> wrote: > Hello, > > Digging further in the ActiveMQ documentation, could the Networks of > Brokers a solution ? > > Best Regards. > > -----Original Message----- > From: COURTAULT Francois [mailto:[email protected]] > Sent: vendredi 26 janvier 2018 18:02 > To: [email protected] > Subject: [+SPAM+]: JMS messages replication > > Hello, > > I have looked at Replicated LevelDB Store page on ActiveMQ web site, even > if LevelDB store has been replaced by KahaDB, in order to see if it can > solve the technical issue I have. > But, as far as I have understood this solution won't solve my problem. > > Let me describe it, in order to really see if the LevelDB Store is not a > solution. > > What I want to have is: > JMS producers & consumers at Location 1 ----------> Location 1 > JMS broker > Location 2 JMS broker <- ------------- JMS producers & Consumers at > Location2 > > | > > | > > Persisted messages at Location 1 > Persisted messages at Location 2 > > But also persisted messages at location 2 replicated at Location 1 and > vice versa , thanks to a synchronization between the 2 JMS brokers or at > persistent level. > > My understanding of Replicated LevelDB Store is that we have a notion of > Master and Slave, managed by ZooKeeper, and in the schema above, let's say > that Location 1 JMS broker is the Master. > In such case, the second JMS broker, Location 2 JMS broker is not able to > accept any client connections, according to your documentation, right ? So > It can't consume JMS producers messages at Location2, right ? > This is why I think I can't use this solution. > > So, is there a solution to my problem using Active MQ ? Yes, using, > instead of KahaDB, a database with a built-in replication. > Cassandra could be used for example, but unfortunately I haven't found the > fact that Cassandra is supported by ActiveMQ. > > Still a blocking point. > > Does it exist a solution to my technical problem using ActiveMQ ? > > Best Regards. > ________________________________ > This message and any attachments are intended solely for the addressees > and may contain confidential information. Any unauthorized use or > disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for > the message if altered, changed or falsified. If you are not the intended > recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission > free from viruses, the sender will not be liable for damages caused by a > transmitted virus. > ________________________________ > This message and any attachments are intended solely for the addressees > and may contain confidential information. Any unauthorized use or > disclosure, either whole or partial, is prohibited. > E-mails are susceptible to alteration. Our company shall not be liable for > the message if altered, changed or falsified. If you are not the intended > recipient of this message, please delete it and notify the sender. > Although all reasonable efforts have been made to keep this transmission > free from viruses, the sender will not be liable for damages caused by a > transmitted virus. >
