DUAS Node CPU Spike after Migrating Jobs to a New Node

Products

• Automic Dollar Universe

Issue/Introduction

After migrating jobs/uprocs from an existing Dollar Universe node to a new node, starting the Node Manager on the new node causes an immediate and sustained spike in VM CPU/load, even with few or no jobs actively running. The system becomes unstable and typically requires a reboot every 1–2 hours to recover. The universe.log is continuously flooded with repeating error messages such as:

|ERROR|X|IO |xn_get_extended_name        | O_TYPE_NODE name not found for ID <OLDNODE>
|ERROR|X|IO |o_io_cache_data_provider_   | Error getting Name for <OLDNODE>: 600
|ERROR|X|DQM|u_dqm_snd_sub_job           | unable to get node id for [NEWNODE]

Jobs already updated to run locally on the new node execute successfully, but the underlying instability and CPU spike persist regardless.

Environment

• Product: CA Automic Dollar Universe 
• Version: 7.01.02
• OS: Linux

Cause

One or more Batch (Generic) Queues on the new node (e.g., SAP, JOB_TECHNIQUES) retained an "Attached Queue" entry still pointing to the original node's physical queue (e.g., OLDNODE:SYS_BATCH) instead of being updated to reference the new node's own physical queue. The original node remains live and in service elsewhere — the issue is purely that the queue configuration on the new node was not repointed to itself during the migration.

Because of this mismatch, the Distributed Queue Manager (DQM) on the new node continuously attempts to resolve the referenced queue-node pairing and fails (O_TYPE_NODE name not found, error 600), retrying indefinitely with no backoff. This retry loop is the direct cause of the sustained CPU spike.

Resolution

Using the UniViewer Console (Batch Queues → affected Generic Queue → Attached Queues), removed the incorrect attached-queue entry pointing to OLDNODE:SYS_BATCH and re-added the same physical queue (SYS_BATCH), correctly attached to the NEWNODE. Once corrected, the repeated errors stopped, CPU/load returned to normal, and job processing resumed as expected.