Tibco EMS Queues Test

The point-to-point style of messaging uses a queue to store messages until they are received. The message producer sends the message to the queue; the message consumer retrieves messages from the queue and sends acknowledgment that the message was received. More than one producer can send messages to the same queue, and more than one consumer can retrieve messages from the same queue. The queue can be configured to be exclusive, if desired. If the queue is exclusive, then all queue messages can only be retrieved by the first consumer specified for the queue. Exclusive queues are useful when you want only one application to receive messages for a specific queue. If the queue is not exclusive, any number of receivers can retrieve messages from the queue. Non-exclusive queues are useful for balancing the load of incoming messages across multiple receivers. Regardless of whether the queue is exclusive or not, only one consumer can ever retrieve each message that is placed on the queue.

For every queue configured on the EMS server, this test enables you to track the length of the queue and its size (in bytes), so that you can be promptly alerted to any abnormal increase in queue length or to any load imbalances experienced by the queue. In addition, the test reports the queue type and the number of receivers to the messages in the queue.

Target of the test : A Tibco EMS Server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each queue on the Tibco EMS server being monitored.

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.


The IP address of the host for which this test is to be configured.


Refers to the port at which the specified host listens to.


Prior to monitoring the Tibco EMS server, you will have to build a .bat or .sh file (depending upon the operating system on which Tibco EMS is functioning) bundled with the commands that the eG agent needs to execute on the Tibco EMS server for collecting the required metrics. The commands to be invoked by the .bat or .sh file are provided in How does eG Enterprise Monitor Tibco EMS?.

The .bat/.sh file so created can be saved to any location on the Tibco EMS host. Then, while configuring this test, make sure you provide the full path to this .bat or .sh file in the CommandPath text box so that, the agent can execute the file, invoke the commands bundled into it, and extract the desired metrics from the server.

Ignore Queues

Specify a comma-separated list of queues to be excluded from monitoring in the Ignore Queues text box. A * can be used in the queue name to indicate leading or trailing spaces. For instance, to ignore queues with names that embed the string sys, your Ignore Queues specification can be: *sys*  

Measurements made by the test
Measurement Description Measurement Unit Interpretation


Indicates the number of currently active receivers in this queue.


Receivers can retrieve messages from the queue. By default receivers can receive multiple messages at the same instant. You can also configure the receivers to receive only one message at a time. The value of this measure will help you ascertain the workload of the queue in terms of the number of receivers it supports. 

Pending messages

Indicates the number of pending messages in this queue.


If the value of this measure increases significantly over time, it could mean that the messages are getting accumulated in the queue. This could primarily be because the producers are sending messages more rapidly than the speed of consumption by the consumers. One of the reasons for this slowdown could be that the consumer has been offline for a long time - this also allows more messages to be enqueued. Connectivity issues faced by the consumer while retrieving messages from the queue could also delay consumption. Regardless of the reason, the queue length should be kept under a check at all times, so as to conserve server resources and the loss of critical messages.

Message size

Indicates the total size of pending messages in this queue.



If the size grows significantly over time, it could indicate that messages are getting added to the queue but are not being consumed quiet as quickly. As already mentioned, the slowdown in consumption can be attributed to the consumer being offline for a long time. Practical issues - such as bad network links - faced by consumers while retrieving messages from the queue can also delay/halt consumption. Regardless of the root cause, the message size should not be allowed to grow uncontrollably, as it may completley erode the storage resources of the server. To limit the growth of a queue, use the the maxBytes configuration for that queue. maxbytes defines the maximum size (in bytes) of all messages that can be waiting in a queue. If this limit is violated, an error is returned to the producers.


Indicates whether the queue is static or not.


The value 0 for this measure indicates that the queue is static, and the value 1 indicates that it is non-static - in this case, the queue can be of type dynamic or temporary. A static queue is typically created statically in the server configuration files, and the dynamic queue is created on-the-fly by applications. The dynamic queues do not appear in the configuration files, and exist as long as there are messages or consumers on the destination. You can identify dynamic queues in the administration tool using the asterisk (*) that will pre-fix their names. Temporary destinations (temporary queues or temporary topics) are proposed as a lightweight alternative in a scalable system architecture that could be used as unique destinations for replies. Such destinations have a scope limited to the connection that created it, and are removed on the server side as soon as the connection is closed. Owing to their short life span, these queues may not have a lasting effect on the load/overall performance of the EMS server.