Logging correlator-integrated messaging for JMS status

s

Number of senders

The current number of JMS senders (both static and dynamic) on all JMS connections.

tx

Sent events

The total number of events sent to all JMS sender channels and which have been fully processed (either sent to JMS or exhausted the maximum failure retry limit). Includes events sent to dynamic senders that have since been removed, but does not include events sent before the correlator was restarted.

sRate

Send throughput rate

The total number of events sent per second across all senders, calculated over the interval since the last status line (typically 5 seconds).

sOutst

Outstanding sent events

The total number of events that have been sent by EPL but are still queued waiting to be sent to JMS.

r

Number of receivers

The current number of JMS receivers (both static and dynamic) on all JMS connections.

rx

Received messages

The total number of messages received from JMS, including messages received but not yet mapped to Apama events and added to the input queue of each public context. Includes events received by dynamic receivers that have now been removed, but does not include events received before the correlator was restarted, nor does it include any JMSReceiverFlowControlMarker events enqueued when the receiverFlowControl is enabled.

rRate

Received throughput rate

The total number of JMS messages received per second across all receivers, calculated over the interval since the last status line (typically 5 seconds).

rWindow

Receiver flow control window size

If receiverFlowControl is disabled for all receivers, this has the special value “-1”. If any receivers have flow control enabled, rWindow gives a measure of the number of events that can be received before all flow controlled receivers will block, calculated as the sum of all the non-negative receiver window sizes. Note that even if this value is greater than 0 there could still be one or more receivers which have exhausted their own windows and are blocked, so consider enabled logDetailedStatus if per-receiver flow control diagnostics are required.

rRedel

Redelivered messages

The total number of JMS messages received with the JMSRedelivered flag set to true, indicating they are in-doubt and may have already been delivered in the past. For many JMS providers this flag is not always set reliably/consistently, but it does at least provide an indication of whether redeliveries may be taking place.

rMaxDeliverySecs

Maximum delivery time

The highest time taken by the JMS broker to deliver a message, based on the difference between the time when each message is received and the value of the JMSTimestamp message header field which indicates the time when it was sent. This is likely to be a low number during normal operation, but will rise during failure modes such as loss of network connectivity or machine crashes as the JMS broker attempts to redeliver messages. This value is useful for understanding the redelivery behavior of the JMS provider in use and for choosing a sensible time expiry window if EXACTLY_ONCE duplicate detection is being used (see dupDetectionExpiryTimeSecs property). A high rMaxDeliverySecs value during testing may indicate that messages remaining on a JMS queue or durable topic from a previous test run may be interfering with the current test run. Note that any difference in the system time on the sending and receiving hosts will add an error to this value, which can result in negative values.

rDupsDet

Duplicate messages detected

The total number of duplicate messages detected by EXACTLY_ONCE receivers and suppressed because their uniqueMessageId was already present in the duplicate detector. Does not include dynamic receivers that have now been removed.

rDupIds

Duplicate ids in memory

The total number of uniqueMessageIds being kept in memory for duplicate detection purposes by EXACTLY_ONCE reliable receivers. This is the total of the size of all per-message-source fixed-size expiry queues plus the unbounded time-based expiry queue. If this becomes too large it is possible the correlator could run out of memory.

connErr

Connection errors

The total number of times a valid JMS connection has gone down. Note that this tracks errors in existing connections and does not include repeated failures to establish a connection.

jvmMB

JVM used memory

The amount of memory used by the JVM in Megabytes (heap plus non-heap), which can be compared with the maximum memory size provided for the JVM to check how much spare memory there is and ensure that the correlator is not close to running out of memory. This is particularly useful for checking peak memory consumption, such as testing when any EXACTLY_ONCE duplicate detectors are fully populated with the maximum likely number of uniqueMessageIds. Note that the memory usage figure reported by the JVM includes both live objects and objects waiting to be garbage collected, so inevitably this will go up and down a certain amount as garbage collections occur.

...

onApplication Initializedindicator

The suffix <waiting for onApplicationInitialized> will be added to the status lines if the EPL application has not yet called jms.onApplicationInitialized() as a reminder that status or JMS message events cannot be passed into the correlator until this action is invoked.