error handling

[andybarker]

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.

[kconner]

"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.

[marklittle]

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

[andybarker]

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.

[kconner]

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.

http://wiki.jboss.org/wiki/AsyncContinuation

[andybarker]

Kevin,

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.

[andybarker]

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

http://jira.jboss.com/jira/browse/JBESB-1395

[kconner]

Hiya Andy.

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

Kev