Skip to main content
Skip table of contents

Monitoring object queues

Object queues are a concurrency control mechanism which supports sending and receiving internal messages between application components. Object queues provide a clean interface for managing flows of integration messages or of asynchronous business logic invocations.

Much of the object queue functionality is implemented in metadata. Developers can therefore directly examine, create, and manipulate messages and queues from business logic at runtime, which is not feasible with third-party queuing modules. In particular, object queues:

  • Contain error handling logic that can be overridden to support advanced error recovery scenarios.
  • Support several concurrency control mechanisms to:
    • Limit load on a server.
    • Guarantee the relative ordering of message deliveries.
    • Limit concurrent access to sensitive resources.
  • Provide hooks, which can be used to gather statistics on message processing and to track progress of parallelized work.

Each application has multiple object queues, which are defined using NexJ Studio before the application is deployed.

You can inspect the object queues and individual messages using the Object Queues page in NexJ System Admin Console. Use this functionality to proactively monitor object queue statistics and to review error and runtime queues. This enables you to resolve performance problems as they occur and to identify potential performance issues before they occur.

You can also resend blocked and waiting messages and change certain properties for a queue. You can update concurrency settings and specify whether a queue can send or receive messages.

For information about validating object queues and monitoring the health of object queues in action, see Monitoring NexJ servers with Grafana.

Message states

Messages in object queues pass through the following states:

The following table describes the states:


The message has been created but has not yet been sent. The message will remain in the New state until it is sent on a queue.

DispatchingThe message is waiting to be transitioned by the dispatcher. Typically, the message needs to be prepared for delivery, or the message needs to be deleted because a worker has completed processing the message. If messages remain in the Dispatching state for more than a minute, this is a sign that the dispatcher is either under heavy load or has stopped running.

The message has been prepared for delivery, but has not yet been handed off to a worker node for processing. Either no threads are available or the system is waiting for a linked message to complete.


The message is being processed by a worker and will either be received successfully or trigger failure logic.


The dispatcher failed to handle the message. This is caused when the queueing engine fails during message processing. It indicates a logic problem in the application code that requires immediate investigation.


The message has been added to a disabled queue (for example, ObjectErrorQueue). The message remains in a Blocked state until it is resubmitted or receiving has been enabled on the queue.

Core object queue channels

The core NexJ business model defines out-of-the-box object queue channels required for the application to behave as designed.

Channels are a key component of NexJ Framework's integration engine. Channels send and receive messages between differing systems using transport adapters. These adapters isolate differences in each system's communication protocol so that, regardless of how a system sends a message, it always interacts with a shared, common interface.


The system queue is the default queue for asynchronous method invocation. It comes preconfigured to use the generic server and is the default queue for (SysQueue'invoke …) and batch jobs.


The error queue does not process messages that are sent to it. It collects messages that have failed to be processed in other queues. An administrator can periodically clear this queue, or can pick out specific messages to be reposted to other queues. The messages in this queue are always in the blocked state.


The dispatcher queue is a specialized queue for sending messages which interact with the object queue dispatching engine, for example, asynchronous invocations which alter messages that are waiting on active queues. Any message sent to the dispatcher queue will block all dispatcher activities while the message is processing. This functionality is intended for advanced use only because while messages are being processed in this queue, other queues are not serviced.

Use the Object Queues page in NexJ System Admin Console to review the details of your application's object queues.

The Object Queues page is divided into three areas.

  • The Object Queues list on the left displays all object queues in your system. You can filter this list to display only specified queues.
  • The summary area on the top right displays summary information about the selected object queue.
  • The details area on the bottom right is divided into three tabs:
    • Detail
      Displays detailed information about the selected object queue. You can change the queue's concurrency settings and whether the object queue can send and receive messages.

    • Statistics
      Displays network performance statistics for each node in the object queue.

    • Messages
      Lists all messages currently waiting on the selected object queue and shows detailed information about a selected message. You can filter the message list to display only messages that fit specified criteria. You can also resend messages that are blocked or waiting.

Viewing details for object queues
Editing settings for an object queue
Viewing statistics for object queues
Viewing messages for object queues
Resending object queue messages
Troubleshooting an accumulation of messages on object queues
Monitoring NexJ servers with Grafana

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.