activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vjaceslavs Klimovs <vklim...@gmail.com>
Subject Re: suitability of configuration for a use case
Date Mon, 19 Jul 2010 10:15:49 GMT
Thanks Dejan!

Two more 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?

On Mon, 19 Jul 2010 10:00:48 +0200
Dejan Bosanac <dejan@nighttale.net> wrote:

> 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
> <vklimovs@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
> >
> >


Mime
View raw message