<p>Delaying redelivery can often be useful in the case that clients regularly fail or roll-back. Without a delayed
redelivery, the system can get into a "thrashing" state, with delivery being attempted, the client rolling back, and
delivery being re-attempted ad infinitum in quick succession, using up valuable CPU and network resources.</p>
<p>Re-delivery occurs when the session is closed with unacknowledged messages. The unacknowledged messages will
be redelivered.</p>
<p>By providing a redelivery delay, it can be specified that a delay of, say, 10 seconds is implemented between rollback
and redelivery. The specific delay is configurable on both a global and per destination level, by using wild-card
matching on the address settings.</p>
<h2>Example setup</h2>
<p>Redelivery delay is specified in the configuration file <ahref="src/main/resources/hornetq/server0/hornetq-configuration.xml">hornetq-configuration.xml</a>:</p>
<p>In this example we set the redelivery delay to 5 seconds for the specific example queue. We could set redelivery delay on
on multiple queues by specifying a wild-card in the match, e.g. <code>match="jms.#"</code> would apply the settings
to all JMS queues and topics.</p>
<p>We then consume a message in a transacted session, and rollback, and note that the message is not redelivered until
<li>And finally, <b>always</b> remember to close your JMS connections and resources after use, in a <code>finally</code> block. Closing a JMS connection will automatically close all of its sessions, consumers, producer and browser objects</li>