eG Help

Generally, each message consumer subscribes to a topic. When a message is published to that topic, all subscribed consumers receives 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.

Measurement	Description	Measurement Unit	Interpretation
Status_Offline	Indicates the current state of this durable subscriber.	Boolean	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.
Pending_messages	Indicates the number of pending messages for this durable subscriber.	Number	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.	KB	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.