2 Replies Latest reply on May 7, 2010 1:50 AM by Thomas Guenter

    Error-Handling and Abort

    Thomas Guenter Newbie



      I'm implementing an application in servicemix using camel. The application basically retrieves messages from a JMS endpoint, routes it through several processors to a producer endpoint and sends the response back to the sender. In the processors and the producer endpoint, several application errors may occur which should be sent back inside the response message.


      The question is: is there a smooth way to handle all application exceptions in the different components and endpoints the same way and to stop the route processing, once an exception occured?


      The solution I came up with is to store exceptions caught inside a processor in a IN-message field and to define a try-catch route. A dedicated error-processor then reads the exception out of the in message and writes the information into the specific fields in the out-message. I also tried to use the Exchange-Exception attribute, but this is alway empty in the next processor.


      However, this solution seems not to be the most appropriate one. I also had a look at error-handler but I couldn't find a way to modify the message itself and to send it back to the sender but to a dead letter queue.


      Version: camel 2.2.0


      Thanks in advance.





      Edited by: tom.guenter on Apr 30, 2010 7:17 AM

        • 1. Re: Error-Handling and Abort
          Claus Ibsen Master

          Error handling is generally hard to do properly.


          Anyway you can read about error handling in Camel from here



          There are links to further wiki pages with more details.

          However the wiki pages may be understand as its more a reference and some insights here and there.


          The Camel in Action book has devoted chapter 5 to error handling in Camel and introduces it from the beginning so you will understand the concepts and principle of error handling in Camel



          You generally use error handler and/or onException to handle errors in a general way. Those can be scoped at either context (like global) or route level (only for this route), with fallback to context level.


          The try .. catch is more like a think to help people to mirror what they would do in regular Java with its try .. catch for error handling. It has its limits as though.

          • 2. Re: Error-Handling and Abort
            Thomas Guenter Newbie



            thanks for your answer. The strategy I currently use is the following:


            Abstract Processors and Producers (my routes only use own producers) catch any exception in the process() method and write it into a dedicated header field. Furthermore they check whether a previous step has encountered any problems. In case it has, then nothing will be done in this step.


            At the end of the route is a result handler, which checks if the exception field contains the exception and does the general exception handling (writing application exceptions into the response for the client and logging system exceptions). An additional route error handler catches any not handled exception and sends the whole message to a dead letter queue.


            In my case, with all processors and producers written by my own, this works fairely good.


            route (simplified):