activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vjaceslavs Klimovs <>
Subject suitability of configuration for a use case
Date Sun, 18 Jul 2010 19:28:10 GMT

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

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:

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. 


View raw message