activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <>
Subject Re: Clustering for HA
Date Tue, 24 Mar 2009 14:54:04 GMT
On Tue, Mar 24, 2009 at 1:17 AM, Erik Drolshammer <> wrote:
> Bruce Snyder wrote:
>> On Mon, Mar 23, 2009 at 10:00 AM, Erik Drolshammer <>
>> wrote:
>>> Hi!
> Good morning :)
>>> We try to set up two brokers according to [1] to get some redundancy in
>>> our
>>> solution. The shared filesystem is based on GFS, but it doesn't seem to
>>> work
>>> that well. The master node use a lot of cpu, but the throughput is
>>> horrible.
>>> Can anyone point me to some resources describing the setup?
>>> Any debug tips?
>> The only setup that's needed for the shared filesystem master/slave is
>> noting the same data directory location for each ActiveMQ instance.
>> That's it. ActiveMQ takes care of the rest based on the filesystem
>> locking.
> I have this element in activemq.conf on two nodes:
> <broker xmlns="" useJmx="true"
>          dataDirectory="${activemq.base}/data">
>   <persistenceAdapter>
>      <journaledJDBC dataDirectory="/home/mq"/>
>    </persistenceAdapter>
> Does this seem correct (and adequate)?
> It seems this setup use DerbyDB and not Kahastore. Is this the only option?
> Are there alternative setups that I might try?

Yes, the journaledJDBC element will use Apache Derby by default, but
you can specify a bean to use as the datasource in the activemq.xml so
that you can use whatever database you prefer.

Other persistence options include non-journaled JDBC as noted here:

If you're using JDBC-based persistence, then you should look at using
JDBC master/slave:

Another persistence option is Kaha persistence as described here:

With this style of persistence, you should use the KahaDB master/slave:

The last persistence option is to use the AMQ Message Store as described here:

This is the default persistence mechanism in ActiveMQ 5.x. If you're
using this style of persistence, then you should be using the shared
filesystem master/slave:

>> According to the Wikipedia entry for the Google File System (GFS), it
>> is mainly used for data that is 'extremely rarely overwritten, or
>> shrunk; files are usually appended to or read.'
>> Given this essential fact, I'd say that GFS is probably not a good
>> candidate for use by ActiveMQ since the ActiveMQ data is in almost a
>> constant churn of being written and removed as messages flow through
>> the broker. Could this be the cause of the high CPU usage and poor
>> throughput?
> Perhaps. Btw, I meant Redhat GFS [1], not Google FS. Do you know if Redhat
> FS is a good solution?
> Or what setup would you recommend?
> We currently use ActiveMQ 5.2.0 on RedHat platform as indicated.

Well, in reading about RedHat GFS it is a distributed, journaled
cluster filesystem and volume manager. In the quick amount of research
I performed I couldn't find any info about performance problems. But
just like any sophisticated filesystem and volume manager, tuning can
be a rather complex task requiring someone with intimate knowledge of
the filesystem and volume manager.

perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"

Apache ActiveMQ -
Apache Camel -
Apache ServiceMix -


View raw message