Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
ActiveMq v 5.5 comes with default message storage configured as KahaDB. Does anyone use it in enterprise level solutions? Should it be replaced with MSSQL instead? And what benefits can each of them have?
The persistence mechanism should be based on your application’s needs. A closely related concern is going to be failover/availability.
Speaking purely of the speed of message persistence, KahaDB is going to be the fastest; it’s tuned specifically for patterns surrounding messaging (writing/reading/discarding). Were you to use something like MSSQL, even with journaling enabled, you’re going to give up orders of magnitude (in mgs/sec) in efficiency. This setup works well if you are concerned with publishing high volumes of messages and are willing to leave message recovery up to an admin or some “invented-here” process.
So, why would you choose a different persistence mechanism? High availability.
Re: something like a relational database, it’s probably something already available in your enterprise, meaning someone’s (hopefully) gone through the effort of clustering and testing disaster recovery. This means you should be able to have a master/slave setup and your messages will be recoverable if a master were to go down. The slave will detect a loss of lock and start using the exact same message store. This setup is ideal if your performance threshold is much lower but you are extremely concerned about up-time and ensuring that you can always publish/subscribe messages.
Regardless, in a well-tuned system, we are talking >= hundreds msgs/sec so performance considerations are likely not going to be your first concern. Should performance really be that crucial, I’d consider looking at something like RabbitMQ, which definitely lends itself well to being extremely efficient at the cost of making high availability more complex to set up.
Here’s a discussion on some of the failover options with ActiveMQ. I’ve settled on using a shared file master/slave setup with a KahaDB being shared on a SAN. Seems to be a nice middle-ground solution.