Hi wezhall, yes, when you want to have an HA JMS node, you will need to chose the "real" architecture: Master and slave using a shared persistence layer in two ways: a) as mutex to determine which process is master and which process is slave and b) for sharing the storage for the persistent queue messages such that the slave can access them immediately when it comes into play
And yes, using a shared JDBC storage is usually slower than the kahaDB storage on a shared file system, but as always, this depends heavily on your environment. And as long as you have a decent environment, you should easily enqueue and dequeue 1000 persistent queue messages per second with a JDBC storage. Once thing you have to keep in mind, though: in any case you are delegating the HA responsibility to your persistence layer. You have to have an HA persistence layer to have an HA JMS node. And that can easily cost you a fortune for either technology. Or you are a smooth operator and go the pragmatic way and set up a stand alone MySQL server, which in practice never fails. :-) And as I said earlier today, providing HA for a JMS node is one thing. Scaling your infrastructure horizontally with a NWOB is orthogonal to this. And yes, you should combine both for queues. You might want to have a look at the slides of my talk at the FUSE Community Day in Frankfurt from last May (if you don't find it too impertinent that I advertise this here): Let's Connect on Vodafone 360 - Using Apache ActiveMQ in Mobile ... Hope that helps. Glück auf! Dirk On Jan 4, 2011, at 7:23 PM, wezhall wrote: > > Hello folks, > > I have been reading the documentation for a little while but I still think I > am only about 80% when it comes to understanding the HA options. > > I have a requirement to handle around 1000 msg per second, without loss, in > a fault tolerant manner. > > Pure master/slave seems out due to the manual recovery process which would > introduce too much delay (plus I would be inclined to set up multiple slaves > if it was an option, which, it seems, is not with this approach). > > I understand that using JDBC master/slave is defined as 'slow', but I am not > sure if this would completely rule out a 1000 msg (1-2k size)/sec > expectation. > > Which seems to leave a shared filesystem as my option. > > However, I have just dreamed up an idea that I am sure will not work for one > reason or another, but I want to run it by the experts here. > > If we configured a network of master brokers, each with a slave, could we > make it so that in the event of failure of one of the masters, the slave > would take over and just deal with the dispatching of any messages currently > 'owned' by that broker (thus dealing with the network-of-brokers problems of > losing the owner, and therefore the message), and then shut down. The effect > would be that the network would be reduced by 1 pair but continue without > message loss. Then, could we manually restart this pair to bring the network > back to full capacity, without any interuption in service? > > Seems like a 'best of both worlds' solution, and maybe too good to be true. > Or maybe even overkill. It just seems that with such a set up, you would > have HA and only local disk writes, so highly available *and* fast... or do > I have it all wrong? :) > > Any input would be gratefully received. > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/1000-msg-sec-with-HA-tp3174084p3174084.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
