JMS subscriptions
Overview
A JMS client must specify the following to subscribe to a JMS topic:
Client IDs
A client ID identifies the JMS client associated with a subscription, and has the following format:
name@ID
where
name uniquely identifies the client
ID uniquely identifies a subscription of the client
JMS topics
A JMS client controls which event messages it receives by subscribing to the appropriate JMS topic. The following table lists the available NFM-P JMS topics. The 5620-SAM-topic-xml topic sends all events. Other topics send specific event types; for example, the 5620-SAM-topic-xml-fault topic sends only fault events.
Table 4-1: JMS topics
Topic |
Description |
---|---|
5620-SAM-topic-xml |
Subscribe to all events. This topic publishes all events with no dependency on other topics. |
5620-SAM-topic-xml-filtered |
Subscribe to all events using an advanced filter to limit the number of JMS messages that are sent. |
5620-SAM-topic-xml-general |
Subscribe to general events, such as object creation and deletion. This topic contains objects that are not in the fault, file, or statistics topics. |
5620-SAM-topic-xml-fault |
Subscribe to fault events. |
5620-SAM-topic-xml-file |
Subscribe to findToFile events. |
5620-SAM-topic-xml-stats |
Subscribe to events related to statistics collection. |
5650-CPAM-topic-xml |
Subscribe to BGP route-change notifications. |
Filters
A JMS subscription must include a filter that, based on JMS header properties, defines the types of event messages that the client receives. A subscription requires only a simple filter, but a client that subscribes to the 5620-SAM-topic-xml-filtered topic can use advanced filters to reduce the volume of JMS traffic.
A subscription to the 5620-SAM-topic-xml-filtered topic enables additional, advanced filtering based on the event properties, or the properties of objects associated with events. See JMS message filtering for information about creating simple and advanced JMS event filters.
Acknowledgment modes
A JMS client must specify one of the following acknowledgment modes:
-
The client automatically acknowledges each message that it receives. After the NFM-P sends a message, it does not send a subsequent message until it receives a message acknowledgment from the client. The efficiency of this acknowledgment mode is highly dependent on network latency.
-
The NFM-P continues to send messages to a client before all previous messages are acknowledged. This acknowledgment mode allows for higher message throughput in high-latency networks, and reduces session overhead and message delays. The communication bandwidth is used more efficiently, and performance is not significantly affected by an increase in network latency.
The NFM-P resends all unacknowledged messages after a communication interruption. Using the AUTO_ACKNOWLEDGE mode, a client may receive one duplicate message if the connectivity failure occurs after the client receives the message and before the NFM-P receives the acknowledgment. Using the DUPS_OK_ACKNOWLEDGE mode, the client may receive several duplicate messages when communication is restored.
The following figure shows DUPS_OK__ACKNOWLEDGE as the message acknowledgment mode. The first parameter of the createTopicSession method is transacted and this must be set to false for acknowledgement mode to be used. Transacted sessions are not supported by the NFM-P.
Figure 4-1: JMS client message acknowledgment mode
topicSession=topicConnection.createTopicSession(false,TopicSession.DUPS_OK_ACKNOWLEDGE ); |
Persistence modes
Two subscription persistence modes are available to a JMS client: durable and non-durable. A durable subscription can persist when a client is not connected; the NFM-P continues to process and store messages for the client. The NFM-P immediately removes a non-durable subscription when the client is no longer connected, and stops processing messages for the client.
The client tolerance for missed events determines whether a durable or non-durable subscription is best. For each subscription type, the NFM-P notifies the client of missed events, after which the client can take corrective action, if required. See Missed events in Connection monitoring and error recovery for more information.