Hi, at first glance I don't see anything wrong with your assumptions and setup. You should try testing it in your environment and see if it works as expected.
Cheers -- Dejan Bosanac - http://twitter.com/dejanb Open Source Integration - http://fusesource.com/ ActiveMQ in Action - http://www.manning.com/snyder/ Blog - http://www.nighttale.net On Sun, Jul 18, 2010 at 9:28 PM, Vjaceslavs Klimovs <vklim...@gmail.com> wrote: > Hi, > > We generally have two types of messages passing through our ActiveMQ > instances. (1) First type needs transacted guaranteed delivery and > high-availability, but the amount of messages of this kind is low, and > latency is not really important. (2) Second type, on the other hand, > needs low latency delivery, and there can be substantial amount of these > messages. However, reliability is not that important. (3) We would also > like to be able to take down brokers as needed, and of course we want > them to come up and resume operations when we are done with doing > whatever we were doing with the respective machine. (4) We don't have > SAN but we have clustered MySQL database. (5) We want to use JMX for > management. > > This is where our findings start. Messages of type (1) should be > sent and received using JMS transactions, and should be persistent. > Messages of type (2) should be sent in auto acknowledgement mode and > should not be persistent. Because of HA requirement in (1) we need to > run two brokers. Because of (3) and (4) the only suitable > master/slave configuration is using JDBC. Because of the (2), small > limits should be placed on queues, and VM cursor should be used. > > Now, how I think this is going to work. Any of the two brokers which > starts first, grabs a lock on the DB, becomes master and starts it's > transport connections. The other one that starts after, does not get a > lock and does not start transport connections. Clients, which are > configured to use failover:// transport, connect to either one and start > exchanging messages, either of type (1) or of type (2). Type (1) > messages are persisted to the database. If the master broker goes down, > slave gets the database lock, starts transport connectors and party > continues. If the one that went down comes up, it becomes slave and > waits for the lock. Type (2) messages are never persisted, and > therefore are very fast. > > Based on all above, I've created configuration for brokers, it is here: > http://pastebin.com/YxV15k8M > > I would be really grateful if someone could look through it, as well as > through my assumptions on the functioning of the system, and see if I > am wrong, missed something, or if something can be done better to > achieve stated requirements. I also have two concrete questions: > 1) Is store usage counted when JDBC persistence is used? > 2) VM cursor and small memory limits are used. Does that mean that > nothing will ever be paged out for non-persistent messages? > > Sorry for the long post. Thank you in advance for any feedback. > > /Vjaceslavs > >
