activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <>
Subject Re: suitability of configuration for a use case
Date Mon, 19 Jul 2010 08:00:48 GMT

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.

Dejan Bosanac -

Open Source Integration -
ActiveMQ in Action -
Blog -

On Sun, Jul 18, 2010 at 9:28 PM, Vjaceslavs Klimovs <> 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:
> 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

View raw message