By default, a broker discards a publication after it has sent that publication to all interested subscribers. However, a publisher can specify that it wants the broker to keep a copy of a publication, which is then called a retained publication.
A copy of a retained publication is sent by the broker to all subscribers who register an interest in the topic of the publication. Therefore, a new subscriber does not have to wait for information to be published again before they receive it.
For example, a subscriber who registers a subscription to a stock price receives the most recently published price straightaway, without having to wait for the stock price to change and be republished.
If RetainPub is specified as a publication option in the Publish message, the publication is retained by the broker and replaces any previously retained publication for that topic.
Because the broker retains only one publication for each topic and subscription point, the old publication is deleted when a new publication arrives.
When deciding whether to use retained publications, consider the following questions.
- Do your publications contain state information or event information?
Typically, event information is not retained, but state information is retained. However, if all of the subscriptions to a topic are in place before any publications are made on that topic, and if no new subscriptions are expected, there is no requirement to retain publications, even for state information, because the publications are delivered to all subscribers as soon as they are published.
Publications that contain state information might not be required to be retained if they are published very frequently (for example, every second). With this frequency of publishing, any new subscriber (or a subscriber recovering from a failure) receives the current state almost immediately after it subscribes.
- Do you want to receive publications only when you request them?
If you use retained publications, subscribers can register by using the PubOnReqOnly option of the Register Subscriber message. Therefore, the broker sends publications to a subscriber only when that subscriber requests an update. The broker then sends the current retained publication to the subscriber that matches the subscription.
- Can retained publications be mixed with non-retained publications on the same topic?
This option is not recommended. If you have a retained publication, and then publish a non-retained publication on the same topic, the existing retained publication is still retained. It is not updated by the non-retained publication. If a subscriber registers by using the PubOnReqOnly option of the Register Subscriber message, it cannot access any non-retained publications. The broker sends only the current retained publication in response to a request for an update.
- Can you have more than one application publishing retained publications on the same topic?
You are recommended to have no more than one application publishing retained publications on the same topic. If you do, and the timing is close to simultaneous, it is indeterminate which publication is retained. If the publishers use different brokers, different retained publications for the same topic might be held at each broker.
- How does the subscriber application recover from failure?
If the publisher does not use retained publications, the subscriber application might need to store its current state locally. If the publisher uses retained publications, the subscriber can request an update to refresh its state information after a restart.
The broker continues to send publications to a registered subscriber even if that subscriber is not running. This option can lead to a buildup of messages on the subscriber queue. This buildup can be avoided if the subscriber registers with the PubOnReqOnly option of the Register Subscriber message. The subscriber must then refresh its state periodically either by requesting an update or by using a temporary dynamic queue.
- What are the performance implications of retaining publications?
The broker has to store retained publications in a database. This option reduces throughput. If the publications are very large, a large amount of disk space is required to store the retained publication of each topic. In a multi-broker environment, retained publications are stored by all of the other connected brokers that have a matching subscription.
Use the Expiry field of the message descriptor (MQMD) to set an expiry interval for a retained publication.
The sample verification applications that are included with
WebSphere® Event
Broker include the following sample:
This sample uses retained publications to record the latest score in each soccer match that it is monitoring. The sample code illustrates the programming that is required to support this option.
You can view samples only when you use the information
center that is integrated with the Message Brokers Toolkit.
Not all applications can publish retained publications, and not all retained publications can have expiry dates applied to them. The following table shows which applications can publish retained publications and whether the retained publications can have an expiry date.
|
MQ |
SCADA |
JMS/IP |
Retained |
YES |
YES |
NO |
Expiry Date |
YES |
NO |
NO |
The columns in the table indicate three types of application. The first row indicates whether a publication can be a retained publication, and the second row indicates whether an expiry date can be applied to the publication.