7 Replies Latest reply on May 13, 2008 5:57 AM by Kevin Conner

    error handling

    Andrew Barker Newbie

      I think I have misunderstood the way the error handling is supposed to work when an Exception (ActionProcessingException) is thrown while a chain of actions is processing.

      I thought that the Error message would be delivered to the address specified in the fault to part of my ESB message, however the full Exception appears to be sent to the reply to endpoint (not the faultTo one).

      I have cheated slightly and set the fault To EPR on my message with the first action I called in the action chain (after receiving a message through the JMS gateway) I can see the fault to value on the message is being set to a service which should deal with the exceptions correctly, but when an exception is thrown the message ends up being passed to the reply to end point.

      I am getting a message onto the ESB through a JMS gateway as part of a request reply pattern, to make sure the correlation ID is not lost I made a one way set of actions which, if successful, sends a JMS message to a temporary queue (specified in the message by the client) with the correct correlation ID.

        • 1. Re: error handling
          Kevin Conner Master


          "andybarker" wrote:
          I have cheated slightly and set the fault To EPR on my message with the first action

          This is the cause of your problem. The ReplyTo/FaultTo settings are the responsibility of the caller to your service and therefore your action has no impact on these.

          Take a look at the gateway composers, for example PackageJmsMessageContents, and try setting one on your gateway to initialise the FaultTo address. You can specify the composer class by including a composer-class property in your gateway definition.

          • 2. Re: error handling
            Mark Little Master

            BTW, this has been made much more explicit in the latest documentation.

            • 3. Re: error handling
              Andrew Barker Newbie

              Mark, Kevin,

              Thanks for your quick responses.

              I am using the 4.2.1GA version of the jbossesb server.

              I have managed to get the Fault To part of the message set, and the response is indeed sent to that queue when I send an ActionProcessingFaultException.

              I appear to have missed the Documentation about this Exception as well, but having read the subversion source code I thought I should be able to access the original ESB message (including all headers, such as correlation ID and original reply queue) in my new message queue, but it appears that the message that i get into the Error Processing service (which should return the fault message to the correct JMS reply queue with a correlation ID) does not have the Header information.

              Please let me know if you think this is the correct behaviour as this will lead to some interesting problems when trying to implement the JMS request/reply pattern.

              • 4. Re: error handling
                Kevin Conner Master

                The correct way to implement the request/reply pattern is to include the information you need in the FaultTo EPR. If you take a look at the following example if should give you some ideas.


                • 5. Re: error handling
                  Andrew Barker Newbie


                  Could you tell me why this example doesn't work on 4.2.1GA? Is it to do with the way the wiretap works or is it deeper in the source code of the esb Message/Pipeline processing?

                  I have set the extension information on the message on my in queue async action. This appears to work if I get the information out during that pipeline of actions, but when I get to the wiretap and the message is passed to my synchronous action the extension information on the message is no longer set.

                  I was wondering if it was a case of it being a problem with one of the actions (in which case i could copy it into my ESB folder from the trunk and use a local version until I can get the server upgraded) or if it was somethign deeper, meaning this strategy of request and repsonse was of no use in 4.2.1GA.

                  Is there a bug report/ticket for the problem so I could have a look what needs to change.

                  • 6. Re: error handling
                    Andrew Barker Newbie

                    Having done some more digging would I be right in thinking the problem is related to this bug report.


                    • 7. Re: error handling
                      Kevin Conner Master

                      Hiya Andy.

                      IIRC there were a couple of issues within the pipeline/fault handling and JBESB-1395 is definitely one of them.