Delivery Delay

The delivery delay feature allows the message producer to specify the earliest time at which a message should be delivered to consumers. This is done by using the setDeliveryDelay() method to set the minimum length of time that must elapse after a message is sent before the EMS server may deliver the message to a consumer.

Whenever a message is sent to destination dest with a non-zero delivery delay for the first time, the server dynamically creates a queue named $sys.delayed.q.dest when dest is a queue, or $sys.delayed.t.dest when dest is a topic.

$sys.delayed queues support browsing and purging but do not support other permissions such as receive or send. They inherit destination limits, security, and storage selection properties from dest. However, note that a $sys.delayed.t queue created for a topic that has the secure property cannot be browsed.

Note that the $sys.delayed queue corresponding to a destination takes any maxmsgs property setting from the destination. That is, if dest has property maxmsgs set to X, its $sys.delayed queue also has maxmsgs set to X. This doubles the number of messages that can potentially be held for dest in the server.

If the maxmsgs limit has been reached and the destination has the property overflowPolicy=rejectIncoming, when the delivery delay expires for a message one of two things can happen. If the message has the JMS_TIBCO_PRESERVE_UNDELIVERED set to true, it is put on the $sys.undelivered queue. Otherwise, the message is discarded.

Note that, when delivery delay is enabled for a topic, the behavior of overflowPolicy=default mimics that of a queue. That is, when maxbytes or maxmsgs has been reached, new messages are rejected by the server and an error is returned to the producer.

Top