An exception destination is a location for messages that cannot be delivered to, or remain on, a specified target destination, but that also cannot be discarded. Exception destinations prevent the loss of messages when this is required by the quality of service specified for a message.
The exception destination that is associated with a destination is used if a message cannot be delivered because the number of delivery attempts to a transactional consumer is exceeded. When you use a specific exception destination for a queue or topic space destination, an administrator can access those undeliverable messages for that destination in one location.
The exception destination that is associated with a link is used if a message cannot be delivered because the target destination is full or does not exist.
An exception destination must be a queue destination, and can be local or remote. The exception destination must already exist before you configure another resource to use that exception destination. If the exception destination is not a queue, or if it does not exist when the message arrives, messages are rerouted to the default exception destination of the relevant messaging engine.
Note that you cannot configure an exception destination for a bus; you must configure an exception destination for each destination on the bus.
Attempts to deliver the message continue. For a service integration bus link, an undeliverable message might block the processing of other messages waiting for delivery to the same destination. For a WebSphere MQ link, an undeliverable message might block the processing of other messages waiting for delivery through that link to the same bus.
The report options that are set in the properties of individual messages can affect exception destination processing. Depending on the report option that is set, when the conditions apply for service integration to send a message to an exception destination, service integration also sends a report message to the reply-to destination of the message, or discards the message instead of sending it to the exception destination, or both.
Service integration cannot guarantee the ordering of messages sent to an exception destination. Because of this, if message order is important, you can configure a bus destination so that it does not use an exception destination. In this situation, the Maximum failed deliveries per message limit specified for the destination is ignored, and the message remains available to consumers. Synchronous consumers repeatedly attempt to get the message; message-driven beans and other asynchronous consumers repeatedly attempt consume the message. This situation continues until either the message is removed from the destination (for example, by an administrator using the administrative console) or the consumer can subsequently process the message without rolling back.