Best practice for error handling with Spring JMS

Question

I'm working on a message based service that queues all incoming requests and handles them later. What is the best practice for handling errors. For example malformed messages or communication errors when sending the information to the next system.

By using transactions it is possible to cope with the latter, however when a message is malformed there is no use to retry it nor keep it. Is there any idea to implement different error handling for different scenarios and if it is, how should it be done?

Thanks!

Shenika

Answer 1

I think you're on the right track. There's three general patterns here:

• The message is valid and can be processed

Normal processing applies.

• The message is valid, but cannot be processed right now

Perhaps some resource you need to process the message is unavailable. In this case, set the transaction to rollbackOnly and the message will be redelivered. Hopefully your JMS implementation supports the notion of delayed redelivery so that you're not reprocessing the same message thousands of times until your MIA resource becomes available again. If not (yeah, I'm looking at you, WebSphere MQ), what I usually do is push the message into another JMS queue reserved for temporarily unprocessable messages and commit. When the MIA resource comes back on line, I procedurally read all the messages off that queue and write them back to the main [original] queue where they're processed to completion.

• The message is invalid

Suppress the exception and commit the transaction. You'll never see that message again. To keep an audit trail of invalid messages:

• Write the invalid message off to a bad queue where it can be examined later on.
• Log out the contents of the message
• Keep a JMX Counter of Invalid Messages (broken out by type, source queue, parsing error etc.)

The main point, though, is to make sure you commit the transaction if you know you will never be able to process that message.

Erotic

Thanks for a very useful answer! This sounds like a good approach. Do you have any experience implementing this with Spring? Right now I'm heavily relaying on the DefaultMessageListenerContainer which makes it slightly harder to perform the proposed action in each event. But I don't want to go to low leve. Any ideas? – Shenika