I have a master/slave AMQ broker setup for JMS messaging. I have two servers that I would like to setup as a master/slave durable consumers using Apache Camel. We've been achieving this by having both servers attempt to connect with the same client ID. One node handles all of the work but if it goes down the other node connects and picks right back up on the work. This has been working fine for having a single consumer at a time but it makes noise in disconnected server's log files with the message
ERROR org.apache.camel.component.jms.DefaultJmsMessageListenerContainer]
(Camel (spring-context) thread #0 - JmsConsumer[global.topic.event]) Could
not refresh JMS Connection for destination 'global.topic.event' - retrying
using FixedBackOff{interval=5000, currentAttempts=12,
maxAttempts=unlimited}. Cause: Broker: broker - Client: client already
connected from tcp://xxx.xx.xx.xxx:xxxx
Is there a proper way to get the functionality that I'm looking to achieve? I was considering having the slave server ping the master to coordinate which one is connected but I'd like to keep the implementation as simple as possible.
Convert your usage of topics on the consumer side to Virtual Topics. Virtual Topics allow you to continue to have existing message flows produce and consume from the topic, but also have consumers listen on specially named queues.
Once you are consuming from a queue, you can implement all the consumer patterns-- exclusive consumer (which allows that hot-standby backup consumer), message groups, parallel consumers, etc.
Related
I have two ActiveMQ brokers (A and B) that are configured as a cluster of network of brokers with a static list.
Normal message consumption and store and forward works as expected. That is: messages on A with no consumers connected will be picked up by a consumer connected to broker B.
I do see that this is not the case for advisory messages.
In my current setup I have an application that is monitoring the DLQ by connecting to the advisory: ActiveMQ.Advisory.MessageDLQd.Queue. I need this to trigger certain actions when messages arrive in the DLQ.
When testing the cluster I don't see any advisory messages for DLQ messages on broker A coming through to my monitoring application connected to broker B.
Any idea how I can have advisory messages also stored and forwarded just like normal queue messages?
Advisory Messages are not really meant for that sort of thing, they are Topic based event information specific to a given broker. The brokers can use them to discover activity on another broker or a client can listen to the broker it is connected to for information on activity there but broadcasting advisories across networks would lead to confusion as you have no context on where the advisory came from or how it was acted on.
We are using ActiveMQ and have defined a network of brokers (2 in our test setup). We have configured the brokers to accept AMQP connections and we have enable "updateClusterClients" and "rebalanceClusterClients" like so:
<transportConnector name="amqp" uri="amqp+ssl://0.0.0.0:5673?maximumConnections=1000&wireFormat.maxFrameSize=104857600&transport.transformer=jms" updateClusterClients="true" rebalanceClusterClients="true"/>
Furthermore, we have build our clients using Qpid JMS. The clients have been configured using a failover-url.
The clients can communicate with each other just fine. Also, when I stop one of the two brokers, they switch to the remaining broker.
However, when I restart the broker, I had expected to see some of the clients move to the new broker. Unfortunately, what I actually see is that they all stay connected to the same broker.
What might be the reason that they don't rebalance themselves?
Also, I would like the clients to spread over the two brokers when they connect initially. Is there a way how I can achieve this?
The ActiveMQ broker does not attempt to rebalance the AMQP clients in the Broker network. There could be a way to accomplish it but it makes some assumptions about the nature of every AMQP client that's connect such as the fact that they all support connection redirects which not all of them do.
Until a better mechanism is defined such that a client can connect and advertise that it is willing to be redirected I don't think you'll see ActiveMQ forcibly dropping connections on AMQP clients to rebalance them.
The broker is able to rebalance OpenWire clients because it knows that an OpenWire client connected with the failover transport will deal with the Connection Control command that requests the client to leave, where a client that is not connect with failover will ignore that command.
I am using the Bunny implementation of RabbitMQ messaging
I have a bash script that provisions a durable topic exchange, a number of durable queues and binds them.
I am using Bunny on both client and server side to send messages between them.
However, I find that on terminating either connection (client/server) that my exchange and queues dissapear. I would like to configure it so that even if the server side fails, the client can still push messages to the queue and they will be processed once the server is back online.
Is this possible with Bunny/RabbitMQ?
I have set up uniform distributed queue with weblogic server 12c. I am trying to achieve order of delivery and high availability with jms distributed queue. In my prototpe testing deployment I have two managed servers in the cluster, let us say managed_server1 and managed_server2. Each of this managed server hosts jms server namely jms server1 and jms server2. I have configured the jms servers with jdbc persistent store. I have enabled server affinity.
I have a producer running such as java queuproducer t3::/managed_server1. I send out 4 messages. From the weblogic monitoring console I see there are 4 messages in the queu since there are no consumers to the queue yet.
Now I shut down managed_server1.
Bring up a consumer to listen on java queuconsumer t3://managed_server2. This consumer cannot consume message since the producer send all the messages to jms server1, and it is down.
Bring up managed server 1, start a consumer to listen to t3://managed_server1 I can get all messages.
Here is my problem say if the managed_server1 went down then there it never came back up, do i loose all my messages. Also if there is another producer sending messages to java queuproducer t3://managed_server2 then order of messages based on the time between these producers are not guanranteed.
I am a little lost, am I missing something. Can unit of order help me to overcome this. Or should I use distributed topic instead of distributed queue, where all the jms server will receive all the messages from producers, but if one jms server where my consumre is listening fails there is only one consumer in my application, when I switch over to other jms server, I might be starting to get messages from the beginning not from where I left off.
Any suggestions regarding the same will be helpful.
Good Question !
" Here is my problem say if the managed_server1 went down then there it never came back up, do i loose all my messages. "
Ans - no you do not loose all your messages, they are stored in the JDBC store configured for the JMS server deployed on managed server 1. If you want the Messages sent to managed_server1 to be consumed from managed_server2 you need to configure JMS migration.
" Also if there is another producer sending messages to java queuproducer t3://managed_server2 then order of messages based on the time between these producers are not guanranteed. Can unit of order help me to overcome this."
Ans - If you want the messages to be consumed strictly in a certain order, then you will have to make use of unit of order (UOO). when messages are sent using UOO, they are sent to one of the several UDQ destinations, if midway that destination fails, and migration is enabled the messages are migrated to the next UDQ destination and new UDQ messages are also delivered to the new destination.
Useful links -
http://www.youtube.com/watch?v=B9J7q5NbXag
http://www.youtube.com/watch?v=_W3EJ8p35lI
Hope this helps.
I have set up a network of brokers exactly as per this post of Bruce Snyder:
Broker 1:
<networkConnector name="amq1-nc"
uri="static:(tcp://localhost:61617)"
userName="system"
password="manager"
/>
Broker 2:
<networkConnector name="amq2-nc"
uri="static:(tcp://localhost:61616)"
userName="system"
password="manager"
/>
I have advisorySupport="false" in the broker tag of both the broker's config XML and started both the brokers.
Then I started the consumer using the command:
ant consumer -Durl=tcp://0.0.0.0:61616
and finally started producer using this command:
ant producer -Durl=tcp://0.0.0.0:61617
All the produced messaged then go in the pending state on the broker running on port 61617 and consumer connected on port 61616 broker never gets the messages.
Does the network of brokers stop forwarding messages without advisorySupport enabled? I thought that was fixed in a recent release. (I'm using activemq 5.4.2 release).
Does ActiveMQ static network of brokers stop forwarding messages advisorySupport is disabled?
Update:
I ran into issues using advisorySupport="false" and staticallyIncludedDestinations.
We use JMS for mostly request-response like described here: http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
We are using a temporary queue on the Producer side to be able to receive response from Consumers and since staticallyIncludedDestinations cannot include these temporary queue names in it, therefore, all the Producers are unable to receive responses back from clients when advisorySupport is disabled.
I am coming to the conclusion that for our scenario advisorySupport cannot be turned off unless there is some other config trick I'm not aware of.
The documentation sais:
"Warning:
Advisory messages are required for
dynamic network broker topologies as
NetworkConnectors subscribe to
advisory messages. In the absence of
advisories, a network must be
statically configured.
The Advisory messages tell a node where remote consumers are and therefore where to send incoming messages. WITHOUT them, you have to configure that stuff yourself.
The documentation has an example how to do that: http://activemq.apache.org/networks-of-brokers.html