Tibco EMS Durables Test

Generally, each message consumer subscribes to a topic. When a message is published to that topic, all subscribed consumers receive the message. Because of this there might be time dependency. By default, subscibers only receive messages when they are active. If the messages are delivered when the subscriber is not available, the subscriber does not receive these messages.

Java Message Service( JMS) specifies a way to remove the part of timing dependency by allowing subscribers to create durable subscriptions. Messages for durable subscriptions are stored on the server until the message expires or the storage limit is reached. Subscribers can receive messages from a durable subscription even if the subscriber was not available when the message was originally delivered.

When an application restarts and recreates a durable subscriber with the same ID, all messages stored on the server for that topic are published to the durable subscriber.

Until such time, the pending messages will remain on the EMS server, consuming machine resources. If the messages are allowed to grow limitlessly in size and number over time, they can drain the server of its resources, thereby choking critical server operations. Using this test, you can continuously monitor the status, activities, and pending messages of durable subscribers, and be proactively alerted if the pending messages appear to be growing significantly in size and/or number. Besides enabling you to control message growth, the metrics reported by this test also enable you to avert impending resource shortages on the server.

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 durable subscriber 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.

Detailed Diagnosis

To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

  • The eG manager license should allow the detailed diagnosis capability
  • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
Measurements made by the test
Measurement Description Measurement Unit Interpretation

Is status offline?

Indicates the current state of this durable subscriber.


If the value of this measure is 0, it indicates that the subscriber is offline, and if the value is 1, it indicates that the subscriber is online.

Use the detailed diagnosis of this measure to know the topics to which the durable subscriber is subscribing.

Pending messages

Indicates the number of pending messages for this durable subscriber.


If the value of this measure increases significantly over time, it could mean that more messages are still waiting to be delivered to subscribers. This could primarily be because, while the publishers are sending messages to the topic quickly, the subscriber is not receiving the messages quiet as quickly. One of the reasons for this slowdown could be a network connectivity issue between the subscriber and the EMS server - a poor network link could be delaying message delivery at one end, while on the other end, the topic may be experiencing a major influx of messages from the publisher. The pending message count can also increase, if the subscriber has been offline for a long time. During this period of inactivity, existing messages will remain undelivered on the server, and more messages may continue to be published to the topic by the publisher, thereby increasing the pending message count. However, regardless of the reason, the number of pending messages should be kept under control at all times, as they consume considerable server resources.

Message size

Indicates the total size of pending messages for this durable subscriber.


If the size grows significantly over time, it could indicate that messages are getting published on the topic but are not being delivered to subscribers quiet as quickly. As already mentioned, the slowdown in delivery can be attributed to the durable subscriber being offline for a long time. Practical issues - such as bad network links - faced by subscribers while receiving messages from the topic can also delay/halt delivery. Regardless of the root cause, the message size should not be allowed to grow uncontrollably, as it may cause a serious resource contention on the server. To limit the growth of pending messages on a topic, use the maxBytes configuration for that topic. For topics, maxBytes limits the total size (in bytes) of all messages waiting for delivery to each durable subscriber on that topic. If this limit is violated, then messages will be go undelivered, thus causing the receivers to lose critical data.

Use the detailed diagnosis of the Is status offline? measure to know the topics to which the durable subscriber is subscribing.

Figure 1 : The detailed diagnosis of the Is status offline? measure