Using missing topic notifications with remote servers

Control client sessions can use missing topic notifications to monitor the activity of end-user client sessions. In response to subscription requests to missing topics, the control client session can choose to take an action, such as creating the missing topic.

For more information, see Handling subscriptions to missing topics.

How notification propagation works

A missing topic notification is propagated from a secondary server to a missing topic handler registered against a primary server, if and only if all of the following conditions are met:

There is an active remote server connection between the secondary server and the primary server which has a 'missing topic notification filter specified.
The selector used for the subscription request to the secondary server matches with no topics on the secondary server.

The selector of the remote server's missing topic notification filter matches the subscription selector. There is a match if the path prefix of the selectors match or if the remote server specifies the special "*.*" selector which matches all.

The primary server has no topics that match the selector used in the subscription request.
One or more missing topic handlers are registered against the primary server for a path that matches the subscription selector. The following rules are used to select which missing topic handler receives the notification:
- If multiple handlers are registered for the branch, the handler for the most specific topic path is notified.
- If there is more than one handler for a path, the Diffusion™ server notifies a single handler.

Example flow

A control client connects to the primary server and registers a missing topic notification handler against the A branch of the topic tree.
A secondary server remote server connection connects to the primary server.
On the secondary server there are currently no topics.
An end-user client attempts to subscribe to A/D, which does not exist.
There is a match between the path prefix of the subscription selector and the missing topic notification filter of the remote server, so the secondary server propagates the missing topic notification to the primary server.
The primary server sends the missing topic notification to the handler registered by the control client. The control client can then create whatever is required to cause the creation of A/D on the secondary server. This differs from fan-out in that it is not necessarily a direct mapping of topics from the primary to the secondary. A/D might be created by a topic view on the secondary server as a result of a different topic being created on the primary server.

Missing topic notification handlers at both the primary and secondary servers

Missing topic handlers can be registered on both primary and secondary servers, however unlike fan-out any registered on the secondary have no impact upon the use with remote servers as notifications are sent over remote server links purely because they have a matching selector.

Considerations when using missing topic notifications with remote servers

The matching of the subscription request with a selector used for a remote server is calculated based only on the path prefix of each selector. Complex selectors that use regular expressions are therefore meaningless as only the path prefix is relevant.

Ensure that the principal that the secondary server uses to make the remote server connection to the primary server has the SELECT_TOPIC permission for the path prefix of the topic views source path selectors.

The topic that needs to be created at the primary server to satisfy the subscription request need not have a path that matches either the subscription selector or the missing topic filter selector. The source topic on the primary server only needs to be selected by a topic view on the secondary server that will generate a reference topic to match the subscription selector.

A current session must exist between the secondary server and the primary server to forward notifications. If there is no session or the session fails while the missing topic notification is in-flight, the secondary server logs a warning message and discards the notification.

The robustness of the session between the servers can be improved by configuring reconnection. Remote server connections can have a large number of messages in flight. It might be necessary to tune the reconnection time-out and increase primary server queue depth and recovery buffer sizes.