Menu
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?
854
References to messages are held in memory, and periodically inserted into the reference store to improve performance. The messages are stored in data logs, which are individual files, typically 32mb in size (though this is configurable, they can be larger if the size of a message is large than the file size).
ActiveMQ has a settings which limits number of messages that can be browsed by a client. By default, it's 400. This setting prevents QueueExplorer to read all (or top 1000, Top 10000, etc) messages from the queue.
ActiveMQ uses memory to store messages awaiting dispatch to consumers. Each message occupies some memory (how much depends on the size of the message) until it is dequeued and delivered to a consumer.
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.
51
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
