exception propagation

[jw]

Hi all

Here a short description of an use case in our app:


ftp adapter (listener, bus??) reads a file
any action in the chain throws an exception (the reason for the exception could be a currently not available resource. So there is a chance that the action succeeds next time).
ftp adapter waits (for a specified time) an reads the file again.


Questions:

How can I do this in ESB?
Is there a way that an action in a chain will be informed about an exception raised by another action later in the chain to do a kind of 'rollback' ?
When I'm right I can specify an error method for an action, but it is called only on the action that has raised the exception. So why not simply use a try/catch block?
Is there a way to define a 'chain-global' exception handler class? I mean a special action that receives all exceptions thrown by any action in the chain?

[burrsutter]

Great minds think alike! :-)
I've been working on a quickstart that demonstrates exactly what you are looking for.

Here is what I'm trying to "prove". It appears that if any action in the pipeline/chain throws an exception then all other action's exception methods are invoked.

At least that is what my current testing shows and I hope to have a working example of this checked in soon.

However, you can demonstrate this for yourself by getting a copy of the quickstart called "custom_action" from SVN here:
http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/samples/quickstarts/custom_action/

Add a final action that just throws an Exception like so:
public Message causesException(Message message) throws ActionProcessingException {
throw new ActionProcessingException("BAD STUFF HAPPENED");
}

Then you'll see all the other exception methods being hit.

[burrsutter]

I have checked in a new quickstart that illustrates how exceptions are presently handled. Note: this is likely to change because we would love your feedback!

http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/samples/quickstarts/exceptions_faults/

Review the build.xml to see all the different ways it can be tested. This example also demonstrates the concept of JMS message selectors.

Burr

[jw]

Hi Burr

Thanks for the example. To make the quickstart custom_action example 'startable' I had to add the exceptionHandler(..) method to the CustomConfigAction class.

When I'm right I can specify an error method for an action, but it is called only on the action that has raised the exception. So why not simply use a try/catch block?

This is not a valid statement. Maybe a did a wrong test or I've tested it with an older version of ESB.






Best Regards,
Juerg

[jw]

Just an idea:
Implement the exception handling methode like the process() metode. Means when it returns the exception passed in, the next exception methode is invoked and when it returns null, no more exception handlers are called.

This would allow to handle some well known exceptions in an action and delegate all others to the next handler.

[burrsutter]

Thanks, I likely have a mismatch in the jboss-esb.xml and the CustomConfigAction class due to rapid fire checkins. :-)

I'll pull a clean copy out and verify it before we ship it. We are in the process of making the majority of the quickstarts go through automated testing.

Burr

[burrsutter]

Just an idea:
Implement the exception handling methode like the process() metode. Means when it returns the exception passed in, the next exception methode is invoked and when it returns null, no more exception handlers are called.

This is a good idea. One scenario that I forgot to test was simply having an action that only had an exception handler and did nothing in its "process" method. I could then put it at the top of the "chain" and know it will be called whenever an error occurs downstream. Then I could just push the message into the MessageStore (or perhaps some JMS queue for errors) and send out an alert for someone to review the message.

Burr

[marklittle]

"burrsutter" wrote:

Just an idea:
Implement the exception handling methode like the process() metode. Means when it returns the exception passed in, the next exception methode is invoked and when it returns null, no more exception handlers are called.

This is a good idea. One scenario that I forgot to test was simply having an action that only had an exception handler and did nothing in its "process" method. I could then put it at the top of the "chain" and know it will be called whenever an error occurs downstream. Then I could just push the message into the MessageStore (or perhaps some JMS queue for errors) and send out an alert for someone to review the message.

You can actually do this at the moment by using the ActionProcessingFaultException (I think that's the name). It lets you return a Message to be delivered and you can set the To field appropriately, i.e., the fault message could be routed to the DLQ/MessageStore.