new ConnectionEvent(type, webSocketUrl, webSocketEvent, timeoutSeconds, countdownSeconds, connectionAttempt)
Event object for MatsSocket#addConnectionEventListener. Note on event ordering: ConnectionEvents are delivered ASAP. This means that for events that the client controls, they are issued before the operation they describe commences: CONNECTING and SESSION_ESTABLISHED. However, for events where the client is "reacting", e.g. when the WebSocket connects, or abruptly closes, they are issued ASAP when the Client gets to know about it: CONNECTED, LOST_CONNECTION, CONNECTION_ERROR and WAITING. For COUNTDOWN, there is not much to say wrt. timing, other than you won't typically get a 'countdown'-event with 0 seconds left, as that is when we transition into 'connecting' again. For events that also describe ConnectionStates, the MatsSocket.state is updated before the event is fired.
The connection attempt count, starts at 0th attempt and increases for each time the connection attempt fails.
For ConnectionEventType#CONNECTING, ConnectionEventType#WAITING and ConnectionEventType#COUNTDOWN, tells how many seconds there are left for this attempt (of the #timeoutSeconds it started with), with a tenth of a second as precision. With the COUNTDOWN events, these come in each 100 ms (1/10 second), and show how long time there is left before trying again (if MatsSocket is configured with multiple URLs, the next attempt will be a different URL). The countdown is started when the state transitions to ConnectionEventType#CONNECTING, and stops either when ConnectionEventType#CONNECTED or the timeout reaches zero. If the state is still CONNECTING when the countdown reaches zero, implying that the "new WebSocket(..)" call still has not either opened or closed, the connection attempt is aborted by calling webSocket.close(). It then tries again, possibly with a different URL - and the countdown starts over. Notice that the countdown is not affected by any state transition into ConnectionEventType#WAITING - such transition only means that the "new WebSocket(..)" call failed and emitted a close-event, but we will still wait out the countdown before trying again. Notice that you will most probably not get an event with 0 seconds, as that is when we transition into ConnectionEventType#CONNECTING and the countdown starts over (possibly with a larger timeout). Truncated exponential backoff: The timeouts starts at 500 ms (unless there is only 1 URL configured, in which case 5 seconds), and then increases exponentially, but maxes out at 15 seconds.
For ConnectionEventType#CONNECTING, ConnectionEventType#WAITING and ConnectionEventType#COUNTDOWN, tells how long the timeout for this attempt is, i.e. what the COUNTDOWN events start out with. Together with #countdownSeconds of the COUNTDOWN events, this can be used to calculate a fraction if you want to make a "progress bar" of sorts. The timeouts starts at 500 ms (unless there is only 1 URL configured, in which case 5 seconds), and then increases exponentially, but maxes out at 15 seconds.
The type of the
ConnectionEvent, returns an enum value of ConnectionEventType.
For several of the events (enumerated in ConnectionEventType), there is an underlying WebSocket event that caused it. This field holds that.
- ConnectionEventType#WAITING: WebSocket CloseEvent that caused this transition.
- ConnectionEventType#CONNECTED: WebSocket Event that caused this transition.
- ConnectionEventType#CONNECTION_ERROR: WebSocket Event that caused this transition.
- ConnectionEventType#LOST_CONNECTION: WebSocket CloseEvent that caused it.
Holds the current URL we're either connected to, was connected to, or trying to connect to.