What is the difference between hub queues, hub temporary queues and hub subscribers?

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)
• CA Unified Infrastructure Management On-Premise (Nimsoft / UIM)
• CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

This document provides information on the difference between queues, temporary queues and subscribers.

Environment

• Release: Any
• Component: UIMHUB

Resolution

Message Queues

Message queues transfer messages to and from the hubs. Queues fall into two categories:

Permanent queues are stored in the local hub database and survive a hub restart. This type of queue ensures that messages are delivered even if the receiver is down when a message is generated.

Example: Nimsoft Alarm Server probe (nas). If the hub running this service goes down and then comes back up, it fetches all alarms generated while it was down. This ensures no alarms are lost.

Temporary queues are used for less-critical communication paths.

Example: Infrastructure Manager sessions. When a user logs in to IM, it creates a temp queue for the user login.

Message Services

The message services in Nimsoft are based on a queue mechanism; the queues are actually physical files (.sds) that contain records with a header and PDS data. Messages are always stored to the queue files; this way no messages are ever lost.

Different types of queues are used for different scenarios:

• Routing of messages to/from other Hubs  
• ATTACH and GET queues
• permanent queues for server probes  
• Post queues
• temporary queues used by clients
• temp queues (temp_xx)

Subscribers

A 'subscriber' is essentially a client that connects to the hub and subscribes to a particular 'Subject' to get messages. Examples of a Subject could be alarm, QOS_MESSAGE, *, etc.

Subscribe mechanism

The subscribe mechanism enables probes and robots to select messages based on Subject rather than on sender address. A client that is configured to receive Nimsoft messages sends a subscribe request to the hub. The client then receives messages matching the subscribed subjects from the hub. A client may use the following methods when subscribing:

Subscribe-> client connects to the hub and gets messages as long as the client is running.

Attach-> the hub configures a message queue to hold the messages if the client is not running.

When the client comes back up, all messages are passed on, including those that were received when the client was inactive.