concept advisory message in category activemq

This is an excerpt from Manning's book ActiveMQ in Action.
Networks by default rely on the remote broker to inform them when the broker is interested in their local messages. For existing active and new message consumers, the destination to which the message consumer is listening is propagated to the local broker’s network connection. The local network connection will then subscribe on behalf of the remote broker’s message consumers for messages to be forwarded across the network. In order for networks to function properly in a dynamic environment, the broker property advisorySupport needs to be enabled (it’s possible to have a statically configured network without enabling advisories). ActiveMQ uses advisory messages to communicate state between brokers (more on this in chapter 14). Because of this, advisory messages are used to forward information about changing message consumers across broker networks as well as clients.
To demonstrate this functionality, we need to create a simple class that uses the advisory messages. This Java class will use the advisory messages to print log messages to standard output (stdout) whenever a consumer subscribes/unsubscribes, or a message is sent to a topic that has no consumers subscribed to it. This example can be run along with the stock portfolio example to make use of the advisory messages (and therefore, certain broker events).
To complete this demonstration, we must modify the stock portfolio producer. ActiveMQ will send an advisory message when a message is sent to a topic with no consumers, but only when those messages are nonpersistent. Because of this, we need to modify the producer to send nonpersistent messages to the broker by setting the delivery mode to nonpersistent. Using the publisher from chapter 3, the following listing shows this simple modification (marked as bold):
Wildcards can be used when subscribing to advisory topics. For example, subscribe to topic://ActiveMQ.Advisory.Consumer.Topic.> in order to receive advisory messages when a consumer subscribes and unsubscribes to all topics in the namespace recursively.
Now let’s take a look at the consumer listeners and how they process advisory messages. First we’ll explore the listener that handles consumer start and stop events, shown next.
Every advisory is basically a regular instance of an ActiveMQMessage object. In order to get more information from the advisory messages, the appropriate data structure must be used. In this particular case, the message data structure denotes whether the consumer is subscribed or unsubscribed. If we receive a message with the Consumer-Info as data structure, it means that it’s a new consumer subscription and all the important consumer information is held in the ConsumerInfo object. If the data structure is an instance of RemoveInfo, it means that this is a consumer that just unsubscribed from the destination. The call to removeInfo.getObjectId() method will identify which consumer it was.
In this example, the advisory message is the actual message sent to the destination. So the only action to take is to print the message to standard output (stdout).