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.