activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Repko, Brian" <>
Subject network of embedded brokers (in Glassfish)
Date Wed, 10 Dec 2008 16:11:13 GMT
We have had a number of issues with the genericjmsra and OpenMQ on
Glassfish V2
and are looking to switch to ActiveMQ (RAR/brokers).  We have that
working now (and 
I intend to put a blog together on that since Ramesh's standard blog is
quite old and 
not really accurate).  With ActiveMQ we can use both direct JMS
as well as MDBs (GF default components don't support direct consumers -
only MDBs
and MDBs in a cluster on a topic do once-per-cluster semantics - not
We are now looking at our options for broker topologies and there in
lies my question.
We have multiple clusters of application servers (2-4 servers per
cluster) - each app 
server cluster will get a cluster of brokers (probably 2 but only for
failover).  GF can create
a network of brokers on startup (external processes with cluster
configuration based on 
the application server cluster).  In trying to mimic that behaviour, I
was wondering if I can
configure the RAR to use a vm:// broker so that clients in that server
connect to it, but 
that those 2 vm:// brokers share the same data - can they do
store/forward to each other
or just work off a SAN or DB for persistence?  What kind of connectivity
does a vm://
broker expose?
We want it so that when one server does down, then the other keeps
working on messages
(producers/consumers are duplicated on both servers) sent by the other
one but that haven't
been processed yet.
Any suggestions or similar topologies that others know work?  Just
trying to save myself
some time in testing various scenarios.

This e-mail message is being sent solely for use by the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.
 If you are not the intended recipient, please contact the sender by phone or reply by e-mail,
delete the original message and destroy all copies. Thank you.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message