The Talon Manual

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Adding enqueuTs to received messages properties.

...

Field

Description

isMessage

Indicates whether the object is a message or not. This will always be true for message trace output

isInboundMessage / isOutboundMessage

Indicates the message direction. Permissible values are in or out. Inbound messages, designated by in, are messages received inbound for processing on the primary or backup. Outbound messages, designated as out, are solicited or unsolicited messages sent by an application.

 

 

messageBus

The bus on which the message was sent/received

(lightbulb) For received messages this value is only set if received from a message bus configured to set the bus name on receipt.

messageChannel

The channel on which the message is sent/received

(lightbulb) For received messages this value is only set if received from a message bus configured to set the channel name on receipt.

messageKey

The resolved message key i.e. the topic on which the message was sent/received

(lightbulb) For received messages this value is only set if received from a message bus configured to set the received channel key on receipt.

messageSender

The system-wide unique id of the message's sender. If outbound, the sender is the AEP engine that output the trace.

messageFlow

(warning) Internal to the X Platform ***

messageSequenceNumber

The message's sequence number. If outbound, then the message sequence number is assigned from the AEP engine's sequence number space it maintains for outbound messages. The difference, in value, between this field and the value of the Stable field indicates the number of outbound messages that are in the outbound 'pipeline' i.e. the number of messages pending acknowledgement from downstream agents.

 

 

graphId

(warning) Internal to the X Platform ***

parentId

(warning) Internal to the X Platform ***

 

 

inMsgsInTransaction

(warning) Internal to the X Platform *** (for transaction correlation)

Note: This field should not be confused with the direction of a traced message. This field actually indicates rather the opposite. It is used in outbound messages to indicates whether the transaction that the outbound message is part of contains inbound messages or not.

outMsgsInTransaction

(warning) Internal to the X Platform *** (for transaction correlation)

Note: This field should not be confused with the direction of a traced message. This field actually indicates rather the opposite. It is used in inbound messages to indicates whether the transaction that the inbound message is part of contains outbound messages or not.

transactionInSequenceNumber

This field contains the inbound sequence number of a message relative to the transaction that it is part of. For inbound messages, this field contains the seuence number of the message (starting at 1) relative to the set of inbound messages that form the transaction. For outbound messages, this field contains the number of the inbound message in the transaction that triggered the outbound message. The transaction inbound sequence number starts at 1 for each transaction.

transactionOutSequenceNumber

This field contains the outbound sequence number of a message relative to the transaction it is part of. For inbound messages, this field is always 0. For outbound messages, this field contains the sequence number of the message (starting at 1) relative to the set of outbound messages emitted by the transaction. The transacton outbound sequence number restarts at 1 for each transaction.

possibleDuplicate

A backup engine in a clustered configured for EventSourcing with ReplicateBeforeSend holds outbound messages in an outbound queue. The primary piggybacks acknowledgements received from downstream for the outbound message sin the replication traffic which clear out the queue. When a primary fails over to the backup, the backup retransmits all unacknowledged messages in the outbound since it treats them as in-doubt. An engine uses this field to mark the message as 'possible duplicates' when retransmitted.

Note: All message retransmission is performed on failover using a separate transaction. Therefore, that specific transaction will not contain any inbound messages, all outbound messages will have the possible duplicate flag set and all messages will have the same transaction id. This transaction is the one that demarcates transactions that were performed by the agent as a backup from the transactions performed by the agent as a primary post failover.

 

 

outTs /
outTsMicros

This field contains the timestamp at which a message was sent by an engineapplication. This fields is always populated by an engine for sends performed on an event sourced backup. However, on a primary, the engine delegates the responsibiity of stamping the outbound timestamp to the concerete message bus binding at play. Please refer to whether the concrete binding deployed support populating this field before relying on its presence.preProcessingTstimestamp does not record the time at which the message was actually written to the wire; a sent message is written to the wire when the transaction that it is part of is committed.

(lightbulb) This field is populated by the engine when application calls sendMessage when it is configured to capture support metadata 
(lightbulb) The timestamps reflect the number of milliseconds (or microseconds) since the epoch.

preProcessingTs /preProcessingTsMicros

This field contains the timestamp just before the message was dispatched for processing to app. This field will always contain is used to provide an HA consistent timestamp for Event Sourcing applications, consequently the value will reflect the same value when dispatched on the primary and all backups in a clusteras that of the Primary when received by a backup via replication or when receovered from a transaction log. This field is guaranteed to be populated and can be relied upon as the time a message was received by the application.

(lightbulb) The timestamps reflect the number of milliseconds (or microseconds) since the epoch.

enqueueTs /
enqueuTsMicros

This field contains the timestamp just before a message was enqueued on an application's input queue. This timestamp can be compared with the preProcessingTs to determine the amount of time that the message spent on an application's input queue (unless the message is one received by a backup instance in which case preProcessingTs will have the Primary's preProcessingTs value.

(lightbulb) This field is populated by the engine when application calls sendMessage when it is configured to capture support metadata 

(lightbulb) The timestamps reflect the number of milliseconds (or microseconds) since the epoch.

Point in Flow

An AEP engine output message trace at different points of the flow of the message through the engine. The highlighted portion above contains the point in the flow of the message at which point the trace was output. The following are the various permissible values:

...