This document provides information on the difference between queues, temporary queues and subscribers
Environment
Release: 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: UMP alarm console portlet. When a user starts UMP, the portlet subscribes to alarm messages and a temporary queue is created. Messages are forwarded to this queue as long as the alarm viewer is active. When the viewer is closed, the queue is removed.
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 that are used for different scenarios:
routing of messages to/from other Hubs GET and post queues
permanent queues for server probes ATTACH 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.
keywords: difference between queues temporary subscribers hub mechanism message messages flow process subscribe client