activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Teira Paz <mte...@indra.es>
Subject Question about embedded jdbc master-slave broker
Date Wed, 20 Oct 2010 08:23:20 GMT
Hello all.
I'm working on a clustered applicance, where every node runs an
application instance. Each of them embeds an activemq broker, all
configured in jdbc master-slave mode.

The application also includes (in the same VM than the broker) some
components producing and consuming messages on the embedded broker. To
accomplish this, I was using provider URIS of the form (supposing that
we have two nodes running on host0 and host1) :

failover:(tcp://host0:port,tcp://host1:port)

This setup just works, but seems to me a waste of resources for clients
in the host0 VM to connect using a tcp socket. So, I started to
experiment with the vm transport protocol, using this kind of provider uris:

failover:(vm://localhost, tcp://host1:port)   -- In host0
failover:(vm://localhost, tcp://host0:port)   -- In host1

This way, the broker starts, and also the clients. but things didn't
work properly (messages delivered to the application using the tcp
transport were not consumed by components connecting using that failover
uri). Firing a JMX console I found out that I was running two different
brokers, one under name 'brokerName' as defined in the broker beans
file, and another one as 'localhost', presumably the one holding the vm
transport.

Trying to avoid this, I changed the internal components provider uri to:

failover:(vm://brokerName, tcp://host1:port)
failover:(vm://brokerName, tcp://host0:port)

This way, I only had a broker, but run into problems due to some
connections trying to start their own broker. I suspect this is caused
by my startup sequence, where the broker is started in a detached
thread, and I cannot guarantee the order. So, I changed the URIs to:

failover:(vm://brokerName?waitForStart=10000&create=false,
tcp://host1:port)?randomize=false
failover:(vm://brokerName?waitForStart=10000&create=false,
tcp://host0:port)?randomize=false

Now, connections wait for the embedded broker to start instead of
creating their own connection-embedded broker, also, I added the
randomize=false parameter to force trying first the local vm transport.

This setup seems to work. Anyway, I'm not sure if this is the best
strategy for what I'm trying to achieve: JDBC Master-Slave setup, with
embedded broker, and local (inside VM) and remote broker clients in all
nodes. Do you see any potential problem with this?

Is the vm transport intended to be used with failover?
Is there any other recommended setup for a cluster of nodes with
embedded brokers?

Best regards.
--
Manuel






Este correo electrónico y, en su caso, cualquier fichero anexo al mismo, contiene información
de carácter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no
es vd. el destinatario indicado, queda notificado que la lectura, utilización, divulgación
y/o copia sin autorización está prohibida en virtud de la legislación vigente. En el caso
de haber recibido este correo electrónico por error, se ruega notificar inmediatamente esta
circunstancia mediante reenvío a la dirección electrónica del remitente.
Evite imprimir este mensaje si no es estrictamente necesario.

This email and any file attached to it (when applicable) contain(s) confidential information
that is exclusively addressed to its recipient(s). If you are not the indicated recipient,
you are informed that reading, using, disseminating and/or copying it without authorisation
is forbidden in accordance with the legislation in effect. If you have received this email
by mistake, please immediately notify the sender of the situation by resending it to their
email address.
Avoid printing this message if it is not absolutely necessary.

Mime
View raw message