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.
Related
My experience with setting up Tibco infrastructure is minimal, so please excuse any misuse of terminology, and correct me where wrong.
I am a developer in an organization where I don't have access to how the backend is setup for Tibco. However we have bandwidth issues between our regional centers, which I believe is due to how it's setup.
We have a producer that sends a message to multiple "regional" brokers. However these won't always have a client who needs to subscribe to the messages.
I have 3 questions around this:
For destination bridges: https://docs.tibco.com/pub/ems/8.6.0/doc/html/GUID-174DF38C-4FDA-445C-BF05-0C6E93B20189.html
Is a bridge what would normally be used, to have a producer send the same message to multiple brokers/destinations or is there something else?
It's not clear in the documentation, if a bridge exists to a destination where there is no client consuming a message, does the message still get sent to that destination? I.e., will this consume bandwidth even with no client wanting it?
If the above is true (and messages are only sent to destinations with a consumer), does this apply to both Topics and Message Selectors?
Is a bridge what would normally be used, to have a producer send the same message to multiple brokers/destinations or is there something else?
A bridge can be used to send messages from one destination to multiple destinations (queues or topic).
Alternatively Topics can be used to send a message to multiple consumer applications. Topics are not the best solution if a high level of integrity is needed(no message losses, queuing, etc).
It's not clear in the documentation, if a bridge exists to a destination where there is no client consuming a message, does the message still get sent to that destination? I.e., will this consume bandwidth even with no client wanting it?
If the bridge destination is a queue, messages will be put in the queue.
If the bridge destination is a Topic, messages will be distributed only if there are active consumers applications (or durable subscribers).
3 If the above is true (and messages are only sent to destinations with a consumer), does this apply to both Topics and Message Selectors?
This applies only to Topics (when there is no durable subscriber)
An alternative approach would be to use routing between EMS servers. In this approach Topics are send to remote EMS servers only when there is a consumer connected to the remote EMS server (or if there is a durable subscriber)
https://docs.tibco.com/pub/ems/8.6.0/doc/html/GUID-FFAAE7C8-448F-4260-9E14-0ACA02F1ED5A.html
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.
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 am using ActiveMQ as a JMS implementation server in my application. Scenario is like, there is a topic over which I have many durable subscribers which consumes the published message and a message listener which save the data from message object to central DB server. There is a producer thread which keeps on publishing persistent message over the same topic. I am using KahaDB for persistent Message Store. As soon as a message is published, kahaDB creates a data log file in message store to persist message until all durable subscriber consume it. I want to know if at any point, I shutdown the JMS server and delete all the data log files, what would be the impact. Will it be just that few durable subscriers will not receive a message which was there in data log files for them to be consumed or is there a possibility that few message didn't got saved in central database which is done by message listener over this topic.
Any hint or help is greatly appreciated......
Thanks in advance.
If you stop and start your broker, regardless of whether you delete your data files or not, topic consumer that have not already received a published message will no longer receive it. The reason behind this is that messages sent to a topic will not be written out to the persistent message store.
Durability and persistence are not the same things. A durable subscription tells the broker to preserve the subscription state in case the subscriber disconnects - any messages sent while the consumer is disconnected will be kept around. A non-durable subscription on the other hand is finite; if a subscriber disconnects, it missed any messages sent in the interim. All messages are stored in memory, and will not survive a broker restart.
Message persistence on the other hand stores messages for eventual delivery. This guards against catastrophic failure, or for later delivery to consumers who might not yet be active.
If you want to broadcast messages using pub-sub, and have the subscriptions appear durable and survive broker restarts you should use virtual destinations instead of durable subscriptions.
No messages, persistent or non-persistent, will survive switching the broker off and deleting the data directory.
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