Message Redelivery and Redirection

JMS receive methods provide for the redelivery of messages that are rolled back when the message cannot be delivered, as in the figure below. JMSJCA, an implementation of the Java Connector Architecture 1.5, provides additional flexibility in the way messages are redelivered, and adds the option of redirecting the messages to another destination. The JMS IQ Manager currently supports these JMSJCA features.

Figure 1–9 Message Rollback and Redelivery

The reason for rolling back a message can be either permanent or transient. If it is transient, the message will eventually be delivered after some number of retries; but if the number of retry/rollback cycles required to redeliver the message becomes large, system resources can be negatively affected. To avoid this situation, a series of progressive delays following a prescribed number of failed retries is introduced into the redelivery process. The default behavior is described in the following table.

You can override this default behavior by configuring your own custom characteristics. You specify the actions you want to be taken after a message has been rolled back by means of a specially formatted string. You append this string to the message server URL when you configure the JMS IQ Manager. The formatting of this string is described in the following sections.

Redelivery Options

Progressive Delay

The format of such a delay is retries:delay, where the number of retries is counted from the original rollback and the delay time is given in milliseconds. The maximum allowed delay is five seconds (5000 ms). The following example shows a string that specifies a delay of 1000 milliseconds following five failed retries. In other words, it specifies no delay for the first five attempts at redelivery, then a one-second delay for each subsequent attempt.

Example 1

5:1000

You can also cascade these delay actions to become progressively longer as the number of retries increases. Entries are separated by a semicolon followed by a space. The following example shows a string that specifies a one-second delay following five failed attempts at redelivery, ana a five second delay following a total of ten failed attempts.

Example 2

5:1000; 10:5000

Delay and Redirect

After a certain number of failed redelivery attempts, you may want to redirect the message to a different target destination, such as a dead-letter queue. The format for redirecting is retries:move(args), where the arguments can be queue:target, topic:target, or same:target.

The argument component same specifies the same kind of message destination as the message source. That is, if the message was received from a queue, it will be sent to a queue; if the message was received from a topic, it will be sent to a topic.

The argument component target can be any string and can include the character $, which is automatically replaced with the original destination name.

The following example shows a string that specifies a one-second delay following five failed attempts at redelivery, a 5–second delay following a total of ten failed attempts, then redirects the message to a dead-letter queue named mydlq after a total of 50 failed attempts.

Example 3

5:1000; 10:5000; 50:move(queue:mydlq)

The following example shows a string that specifies a one-second delay following five failed attempts at redelivery, a five second delay following a total of ten failed attempts, then redirects the message to a dead-letter queue after a total of 50 failed attempts. If the message was received from a source destination named Queue1, the message will be redirected to a target destination named dlqQueue1error.

Example 4

5:1000; 10:5000; 50:move(queue:dlq$error)

Delay and Delete

After a certain number of failed redelivery attempts, you may want to simply delete the message. The format for deleting is retries:delete. The following example shows a string that specifies a one-second delay following five failed attempts at redelivery, a five-second delay following a total of ten failed attempts, then deletes the message.

Example 5

5:1000; 10:5000; 50:delete

Specifying Redelivery Options in the JMS IQ Manager

You can specify the actions you want to be taken after a message has been rolled back by appending a redelivery-handling string to the message server URL when you configure the JMS IQ Manager. These actions then override the default actions for all JMS clients interacting with the JMS IQ Manager. The format for this string is:

?JMSJCA.redeliveryhandling=action

where action is the string specifying the delay/redirection/deletion as given in the examples of the preceding section. The following figure illustrates how this string would be specified in the property dialog in the NetBeans^TM IDE.

Figure 1–10 JMS IQ Manager Configuration Properties - Redelivery Example

Specifying Redelivery Options in a JMS Client

You can also specify the actions you want taken for a specific JMS client when specifying the configuration properties for that client, as shown in the following figure. If you do so, the properties you specify for the JMS client will override the redelivery properties specified by the JMS IQ Manager for that client only.

For descriptions of the JMS client redelivery configuration properties, see JMS Client Configuration, or Configuring JMS Clients.

Figure 1–11 JMS Client Configuration Properties - Redelivery Handling