Hi,
ktrue wrote:
3. The previous developers on the project used a network of brokers
topology and had a broker in
each of the clients as well. However, when the client's JMS
connection factory used a failover:(vm://client)
transport for the brokerURL, it never actually worked. When the
server went offline and came back online
it would never reconnect. Given my current understanding
(admittedly
shallow), I don't see the need/benefit
of embedding brokers in the client except that (in relation to
question 2), there are configuration options for
persistence of messages. Is there something I'm missing.
Adrian Co a écrit :
For me, one of the key use of embedding brokers in the client, is that
clients can continue processing stuff even when the remote broker is
down. AFAIK, using the failover protocol, will block the sending of a
message until the client is able reconnect to the broker. If you use
an embedded broker, messages will be persisted automatically, and be
sent when the remote broker comes online again, and the actual
producer need not worry about it. I don't think theres not much use
for a failover:vm://client as using an embedded broker assumes that if
a broker goes down, the client in essence is also down.
I am also very interested by that type of solution.
This is the architecture one we are testing now (ActiveMQ version: 4.0.2
or 4.1). But as far I understood how things work, and within my small
experience of repeatedly unsuccessfull tries, I never manage to see a
disconnected broker reconnecting automatically to other ActiveMQ brokers
in a network of brokers, and then sending messages.
cf. also http://issues.apache.org/activemq/browse/AMQ-895. Related?
Is it true?
If not, what is the configuration to use to have a network of brokers
with automatic reconnection of brokers?
Thanks by advance!
