0 Replies Latest reply on Jul 12, 2011 8:21 AM by Billy Sjöberg

    Advice on error handling strategies for JMS-JCA based flows

    Billy Sjöberg Newbie

      Hi all,


      I'd like to hear some discussions regarding best practices when it comes to persistent, transactional QoS JMS messages.

      At my project we're just starting implementing a messaging bus on AS6, JBEsb 4.10 and HornetQ. The scope is fairly straight forward with just simple one-way messaging patterns coupled with some smooks transformations and in the most advanced cases some filtering/routing.


      The integrity and durability requirements however are pretty high as it is a mission critical system with a lot of very important messages that simply cannot be lost. As all services are one-way mediations I'm obvisously looking at JMS for the QoS it gives us.


      Now if my tests are correct it seems that the JMS-JCA provider is the only one which can guarantee that a message can never be lost. I've done some rough tests where I put the action pipeline to sleep while killing the JBoss process and indeed, the messages could be replayed when the server was brought up again. If exceptions occur during pipeline processing I've also managed to get them rolled back to Hornet's DLQ.


      In the case of an exception however, the message that gets rolled back to the DLQ is the internal "ESB message" and not the raw gateway message that the sending application originally sent. This obviously has to do with the architecture of the ESB having gateways that wraps the message and resubmits it to an internal ESB queue.

      This poses difficulties for the maintenance team as they cannot easily identify the message, its content etc...

      My intention is to make it easy for the operations team to resubmit eventual DLQ messages after i.e. a bug fix or by fixing the message by using a JMS admin tool such as Hermes JMS or similar. This would be much simpler if they had the original message to work with instead of the ESB format.


      I've considered having a fault service which simply logs eventual dead messages before submitting them to a specific backout queue using a regular JMSRouter action. But would this design guarantee no message loss?


      So, to sum it up... Is there anyone who has advice on what works, what to avoid etc in this kind of environment?