# 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.delaye`d 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.

Copyright © Cloud Software Group, Inc. All rights reserved.