What information is contained in the q1.rdb and q2.rdb files?

Products

• DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

What do the files "q1.rdb" and "q2.rdb" files contain?

If these files are deleted or renamed, can the information in them be retrieved?

Environment

DX UIM - All Versions
robot/controller - all versions

Resolution

What q1.rdb / q2.rdb are

They're the local message spool files for the robot's Spooler process (NimBUS/core/robot/Spooler/), which buffers alarm/QoS/data messages on their way to the hub. 

Why there are two files (ping-pong queues)

The Spooler keeps a queue.in pointer and a queue.out pointer, each aliasing either q1 or q2 on startup.

• queue.in — where newly generated messages are appended (messages sent by probes)
• queue.out — where messages are copied to be read from and sent to the hub, then marked as read.

They never write and read the same file at the same time. Instead:

1. New messages always append to in.
2. The flush loop drains from out.
3. Once out is fully drained (0 records) and in has records, they swap roles: the drained file becomes the new in, and the file that was being written becomes the new out to drain next.
4. Whichever file just became empty gets truncated to 0 bytes so it doesn't grow forever with dead space.

This means at any moment one file is "filling up" while the other is "draining and eventually gets truncated" — classic double-buffering, so the robot never has to stop accepting new alarms just because it's mid-send on the other queue, and files get periodically zeroed instead of growing unbounded.

Practical implications

• On disk in the robot's working directory you'll typically see q1.rdb and q2.rdb; one is usually near-empty (just truncated) and the other holds the current backlog.
• queue_size_limit (raw config option for spooler) caps each file's size — if a file exceeds this, oldest/lowest-priority messages get dropped rather than growing without bound.  This value is set in kB (5000 = 5MB)
• If you're debugging queue buildup (e.g., robot losing hub connectivity), q1.rdb/q2.rdb sizes and record counts tell you how much backlog is queued locally.  These values can be observed by using the Probe Utility (CTRL+P in Infrastructure Manager) to execute the "get_info" callback against the spooler.