|
|
|
|
|
|
|
|
|
|
|
Length of time that message will live before expiration. If set to 0, message does not expire. The time-to-live is specified in milliseconds.
If the server expiration property is set for a destination, it will override the JMSExpiration value set by the message producer.
In EMS version 4.4 and later, clients automatically synchronize their clocks with the server when a connection is created. However, for long-lasting connections, Network Time Protocol (NTP) is the most reliable method for ensuring continuing synchronization between server and client. Additionally, if your EMS server or client application are based on a version of EMS prior to 4.4, you must ensure that clocks are synchronized among all the host computers that send and receive messages, if your client application uses non-zero values for message expiration. Synchronize clocks to a tolerance that is a very small fraction of the smallest message expiration time.
|
|
|
Uses a numerical ranking, between 0 and 9, to define message priority as normal or expedited. Larger numbers represent higher priority.
See Message Priority for more information.
|
|
|
|
|
|
Timestamp of time when message was handed off to a provider to be sent. Message may actually be sent later than this timestamp.
|
|
|
This ID can be used to link messages, such as linking a response message to a request message. Entering a value in this field is optional. The JMS Correlation ID has a recommended maximum of 4 KB. Higher values may result in the message being rejected.
|
|
|
|
|
|
|
|
|
If this field is set, it is possible that the message was delivered to the client earlier, but not acknowledged at that time.
|
In the properties area, applications, vendors, and administrators on JMS systems can add optional properties. The properties area is optional, and can be left empty. The JMS specification describes the JMS message properties. This section describes the message properties that are specific to EMS.
TIBCO-specific property names begin with JMS_TIBCO. Client programs may use the TIBCO-specific properties to access EMS features, but not for communicating application-specific information among client programs.
The EMS properties are summarized in Table 5 and described in more detail in subsequent sections in this chapter.
If a message expires or has exceeded the value specified by the maxRedelivery property on a queue, the server checks the message’s
JMS_TIBCO_PRESERVE_UNDELIVERED property. If
JMS_TIBCO_PRESERVE_UNDELIVERED is set to true, the server moves the message to the undelivered message queue,
$sys.undelivered. This undelivered message queue is a system queue that is always present and cannot be deleted. If
JMS_TIBCO_PRESERVE_UNDELIVERED is set to
false, the message will be deleted by the server.
To make use of the undelivered message queue, the application that sends or publishes the message must set the boolean
JMS_TIBCO_PRESERVE_UNDELIVERED property to
true before sending or publishing the message.
You can only set the undelivered property on individual messages, there is no way to set the undelivered message queue as an option at the per-topic or per-queue level.
You should create a queue receiver to receive and handle messages as they arrive on the undelivered message queue. If you wish to remove messages from the undelivered message queue without receiving them, you can purge the
$sys.undelivered queue with the administration tool, using the
purge queue command described under
Command Listing. You can also remove messages using the administrative API included with TIBCO Enterprise Message Service.
Note that $sys.undelivered ignores the
global destination property setting. Messages in the undelivered message queue are not routed to other servers.
Within a message, EMS can supply the user name given by the message producer when a connection is created. The
sender_name and
sender_name_enforced server properties on the destination determine whether the message producer’s user name is included in the sent message.
When the sender_name property is enabled and the
sender_name_enforced property is not enabled on a destination, message producers can specify that the user name is to be left out of the message. Message producers can specify the
JMS_TIBCO_DISABLE_SENDER boolean property for a particular message, and the message producer’s user name will not be included in the message. However, if the
sender_name_enforced property is enabled, the
JMS_TIBCO_DISABLE_SENDER property is ignored and the user name is always included in the message.
EMS supports messages up to a maximum size of 512MB. However, we recommend that application programs use smaller messages, since messages approaching this maximum size will strain the performance limits of most current hardware and operating system platforms.