views:

333

answers:

1

Hi,

reading the ActiveMQ documentation (we are using the 5.3 release) I find a section about the possibility of using a JDBC persistence adapter with ActiveMQ.

What are the bennefits? Does it provide any gain in performance or reliability? When should I use it?

+3  A: 

In my opinion, you would use JDBC persistence if you wanted to have a failover broker and you could not use the file system. The JDBC persistence was significantly slower (during our tests) than journaling to the file system. For a single broker, the journaled file system is best.

If you are running two brokers in an active/passive failover, the two brokers must have access to the same journal / data store so that the passive broker can detect and take over if the primary fails. If you are using the journaled file system, then the files must be on a shared network drive of some sort, using NFS, WinShare, iSCSI, etc. This usually requires a higher-end NAS device if you want to eliminate the file share as a single point of failure.

The other option is that you can point both brokers to the database, which most applications already have access to. The tradeoff is usually simplicity at the price of performance, as the journaled JDBC persistence was slower in our tests.

We run ActiveMQ in an active/passive broker pair with journaled persistence via an NFS mount to a dedicated NAS device, and it works very well for us. We are able to process over 600 msgs/sec through our system with no issues.

Steven Mastandrea
Yeap, that was exactly my experience.In our tests, the JDBC persistence was many times slower than the journalling option.Thanks
Kico Lobo