On Wed, Apr 4, 2018, 11:51 PM SubashKunjupillai <subas...@ericsson.com> wrote:
> Hi, > > We have been using ActiveMQ 5.x (upgraded to 5.14 last year) for our > product > which is in production for 3years. We have been facing stability issues > with > replicated LevelDB store(it was deprecated by community after we went live > with LevelDB, we have stuck to it as we accomplished HA through replicated > message store which is not available in KahaDB). Now we have reached a > threshold point where we can't withstand any further LevelDB corrupt and > lose the messages store over there. > > We are looking for the possible way forward to solve this and it would be > great if the community can help us on identifying the right solution. > > Just a high level picture on our architecture. We have 3 brokers running in > three machines with N number of producers and N number of consumers which > can be scaled independently. 3 instance of brokers are maintained to > provide > HA using replicated LevelDB, so that even at 2 node failure, message queue > is available with zero loss of messages. > > 1) Replace LevelDB with KahaDB and use Hadoop NFS (Faster than traditional > NFS provided by hadoop distributor MapR) to persist KahaDB data. So that > even if two of the broker goes down, the other broker can work on the data > available through Hadoop NFS. I guess it would same as Shared File Storage, > so this should work. Please confirm. > I'd be very skeptical about whether a Hadoop-based NFS implementation provides exclusive locks that are compatible with ActiveMQ's needs. I strongly recommend you test that thoroughly before committing to this path. NFS mount settings are the subject of several currently-active threads on this mailing list, so you can see the settings some other people have used. I'd also be very skeptical about whether a Hadoop-based NFS implementation is fast enough to support constant read-write activity on a small set of files, though it's not something I've ever researched personally so I may be overly pessimistic here. 2) Replace ActiveMQ 5.x with ActiveMQ Artemis. I can understand from the > Artemis documents that the replicated message store option is available. If > Artemis is chosen, we are speculating about the code changes and efforts > required to adapt the same when it will be release as ActiveMQ 6.x. Please > en light me on these. > I'd be surprised if the Artemis codebase changes at all when it becomes 6.x, so I don't think you have to worry about any effort to change your code later just because you start using Artemis now (before it's 6.x). Moving to Artemis seems like the best path forward for what you've described as your needs. Tim >
