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.
