Resolution:
Description:
=========
How UTC offsets are derived.

Environment:
==========
All

Symptoms:
========

If you look in the logs, you will sometimes notice the UTC offsets in the following format:

- 2011-01-08 13:07:54:789 [EMS-Server@ENTESTBNB] UTC offset=417

Solution:
======
When an EMS client connects to an EMS server, during the protocol handshake, the EMS client library computes the difference between the EMS Server's UTC time and its own UTC time. This calculated difference is referred to as the UTC Offset - the value that is calculated is written to the EMS log whenever a client creates a new connection (either due to a new connection or a reconnection of an existing connection).

The UTC offset is used by the client library and the server for the message timestamp and expiration time. Effectively, the message timestamp and expiration appear as if they were based on the EMS Server's time. In this way, message expiration occurs correctly, even if the system clock of the client and the system clock of the EMS server are not in sync.

However, because the UTC offset is calculated by comparing the timestamp of when the client initiates the connection request to the timestamp following when the connection is created successfully, several factors may cause the UTC offset to incorrectly reflect the difference between the two system clocks:

  1. network latency between the client and server
  2. a lack system resources of the server, delaying the creation of new connections
  3. a large number of concurrent connection requests

Additionally, this offset is not consequently recalculated during the lifetime of the connection. This means that if the system clock on either the client's box or the EMS Server's box changes after the connection establishment, the UTC offset will not be correct any more.

If the UTC offset is not a correct representation of the difference of system clock times between the client and the server, delayed and/or premature message expiration may occur.

After the server expires a message, whether prematurely or not, depending on the TIBCO_JMS_PRESERVE_UNDELIVERED property on the message, the message will either be lost, or will be placed in the $sys.undelivered queue.