new InitiationProcessedEvent(endpointId, clientMessageId, sentTimestamp, sessionEstablishedOffsetMillis, traceId, initiationMessage, acknowledgeRoundTripMillis, replyMessageEventType, replyToTerminatorId, requestRoundTripMillis, replyMessageEvent)
(Metrics) Information about Client-to-Server SENDs and REQUESTs (aka Client Initiations), including
experienced round-trip times for both Received acknowledgement, and for Requests, the Request-to-Reply time.
For each message that, for sends, has been acknowledged received, and for requests, has been replied to, gives
this information:
- Client MessageId (envelope's 'cmid').
- Timestamp of when message was sent.
- Target MatsSocket Endpoint or Terminator Id (envelope's 'eid').
- TraceId for the SEND or REQUEST (envelope's 'tid').
- The outgoing message, i.e. the SEND or the REQUEST message (envelope's 'msg').
- Experienced Received Acknowledge round-trip time.
- For Requests, the Reply's MessageEventType
- For requestReplyTo Requests, the replyToTerminatorId.
- For Requests, the total experienced Request-to-Reply time.
- For Requests, the Reply MessageEvent object.
InitiationProcessedEvents
using
MatsSocket#addInitiationProcessedEventListener(), and you may get the latest such events from the
property MatsSocket#initiations.
Note on event ordering:
- send: First ReceivedEvent is issued. Then an InitiationProcessedEvent is added to MatsSocket#initiations, and then all InitiationProcessedEvent listeners are invoked
- request/requestReplyTo: First ReceivedEvent is issued (i.e. ack/nack), then when the reply comes back to the server, an InitiationProcessedEvent is added to MatsSocket#initiations, and then all InitiationProcessedEvent listeners are invoked, and finally the MessageEvent is delivered, either as settling of the return Reply-Promise (for 'request'), or invocation of the Terminator's message- or rejectCallbacks (for 'requestReplyTo').
Parameters:
Name | Type | Description |
---|---|---|
endpointId |
string | |
clientMessageId |
string | |
sentTimestamp |
int | |
sessionEstablishedOffsetMillis |
float | |
traceId |
string | |
initiationMessage |
Object | |
acknowledgeRoundTripMillis |
float | |
replyMessageEventType |
MessageEventType | |
replyToTerminatorId |
string | |
requestRoundTripMillis |
float | |
replyMessageEvent |
MessageEvent |
- Source:
Members
acknowledgeRoundTripMillis :float
The experienced round-trip time for the Received Acknowledgement - this is the time back-and-forth.
Note that this number can be a float, not necessarily integer.
Type:
- float
- Source:
clientMessageId :string
The Client MessageId of the Initiation (envelope's 'cmid'). For this particular MatsSocket library, this
is currently an integer sequence id.
Type:
- string
- Source:
endpointId :string
Target Server MatsSocket Endpoint or Terminator Id (envelope's 'eid').
Type:
- string
- Source:
initiationMessage :Object
The message object that was sent with the initiation, i.e. on send(), request() or requestReplyTo() (outgoing envelope's 'msg').
Type:
- Object
- Source:
replyMessageEvent :MessageEvent
The Reply MessageEvent that was supplied to the Promise (on resolve/then or reject/catch) or ReplyTo
Client Terminator.
Type:
- Source:
replyMessageEventType :string
The MessageEventType for Replies to Request Initiations.
Type:
- string
- Source:
replyToTerminatorId :string
The 'replyToTerminatorId' for MatsSocket#requestReplyTo()-Requests.
Type:
- string
- Source:
requestReplyRoundTripMillis :float
The experienced round-trip time from a Request initiation to the Reply (RESOLVE or REJECT) comes back.
Note that this number can be a float, not necessarily integer.
Type:
- float
- Source:
sentTimestamp :int
Millis-from-epoch when this initiation was sent.
Type:
- int
- Source:
sessionEstablishedOffsetMillis :float
The number of milliseconds offset for sending this message from the initial ConnectionEventType#SESSION_ESTABLISHED event for
this MatsSocket - this number will typically be negative for the first messages: A negative number
implies that the message was sent before the WELCOME was received, which again implies that the very first
message will by definition have a negative offset since it is this message that starts the HELLO/WELCOME
handshake and is thus enqueued before the WELCOME has been received. This is desirable: Upon application
startup, stack up all requests that you need answer for to show the initial screen, and they will all be
sent in a single pipeline, directly trailing the HELLO, their answers coming in as soon as possible after
the WELCOME.
Note that this number can be a float, not necessarily integer.
Type:
- float
- Source:
traceId :string
TraceId for the initiation - which follows through all parts of the processing (envelope's 'tid').
Type:
- string
- Source:
type :InitiationProcessedEventType
Which initiation type of this flow, enum of InitiationProcessedEventType.
Type:
- Source: