Stuck on how to handle my exceptions

[Mark Fisher]

Actually, before my next real question, I would like to ask if the comment I made about Exceptions being "thrown back" makes sense? I think you are just seeing the rollback behavior, correct? Otherwise, I need to understand what you meant by "thrown back".

Thanks,
Mark

[plecesne]

You're right.
I was just seeing that my ErrorHandler was executed, and that the transaction was rollbacked, but no idea in what order.

[Mark Fisher]

Okay. So, my next question is... are the Exceptions expected from a certain component within the pipeline, or do you really expect that *un-caught* Exceptions might occur in a number of different places.

The reason I'm asking is that 2 ways to handle this could be 1) explicitly catch Exceptions where they are considered "non-fatal" and expected or 2) apply an AOP proxy to the component(s) that may propagate Exceptions.

[plecesne]

I could identify four cases we have to deal with:

Case 1: Some exceptions are expected and can be catched (within the POJO class of a <service-activator> for example).
However, in case an exception occurs, we don't want the service-activator to return a valid result: the regular flow must end there and the message must be redirected to an "error-handling" flow. Knowing this, letting the exception propagate (instead of catching it) until a "ErrorHandler" catches it didn't seem such a bad idea.

Case 2: Some exceptions are expected but can't be catched because the POJO class of the service-activator belongs to an external library and is not modifiable.

Case 3: Some exceptions are expected but can't be catched because the endpoint is purely Spring Integration code. For instance, we can't catch an exception if the <int-xml:jaxb2-unmarshaller> fails because the XML is not correct.

Case 4: Unexpected exceptions. There are always cases we can't foresee before a Production use. We don't want the surprise of having a "looping" message in Production because we forgot to catch an Exception somewhere.

In all four cases, the exception is "fatal", the failing message has to exit its normal flow and should enter an "error-handling flow" (where it will be stored and an emailed for instance).

To sum up, all exceptions are considered "fatal" and have to be processed by what I call the "error-handling flow" (which we would like sometimes to be different depending on the exceptions and in which endpoint the exception occurred, but that's just bonus ).

--

I'm not sure to understand how to apply your suggestions to my use cases:

(1): If all the exceptions that occur are considered 'fatal', I guess that solution (1) doesn't apply?
(2): Is it possible to apply an AOP proxy to an endpoint such as <message-driven-channel-adapter> (which would then catch all uncaught and unexpected exceptions of my flow -- would be nice!) or <xml:unmarshalling-transformer> (which would then catch only the exceptions that occur in that transformation)?
If so, that would solve it all (at the price of a few AOP Proxy, but this sounds reasonable).

[EDIT]
Actually, I'm not sure that it would solve it all... If the AOP Proxy can catch the exception and send the message on the "error-handling flow", what will happen on the regular flow once the Proxy has done its job? I guess, a valid output is still expected so the flow can continue... :-/

[plecesne]

Hi Mark, Oleg,

Does my answer make sense for you?
Do you have any idea about how I could handle those 4 types of exceptions regarding my constraints (basically, having a synchronous flow and a transactional context)?

Thank you!

[oleg.zhurakousky]

We are still debating it stand by

[plecesne]

We had a few thoughts about it in my team too and we think having found a (temporary?) solution:

Defining our own TaskExecutor, which is actually a mix of the existing SyncTaskExecutor and ErrorHandlingTaskExecutor : a TaskExecutor that would just run the task synchronously and send any exceptions to an errorHandler.

Something that will probably look like the following class:

public class SyncErrorHandlingTaskExecutor extends SyncTaskExecutor {

	private ErrorHandler errorHandler;
	
	@Override
	public void execute(Runnable task) {
		Assert.notNull(task, "Runnable must not be null");
		try {
			task.run();
		} catch (Exception e) {
			getErrorHandler().handleError(e);
		}
	}

	public ErrorHandler getErrorHandler() {
		return errorHandler;
	}

	public void setErrorHandler(ErrorHandler errorHandler) {
		this.errorHandler = errorHandler;
	}

}

Then, any channel could have this task executor set to its dispatcher.
Any channel could also have a different ErrorHandler if needed.
--

Mark, Oleg,
What do you think about this solution? Do you see any obvious drawback or major issue?

[Mark Fisher]

After lengthy discussions, we have created the following issue:https://jira.springsource.org/browse/INT-1623

You will see that it's a slightly different approach to anything we've had before. We will be adding the "error-channel" option to gateways as well as "inbound-channel-adapter" elements. The description there should be relevant in both cases, except for the use-case where a valid reply Message is generated from the Exception.

Please let us know if that issue sounds like it will address your needs. You can comment directly in JIRA.

Thanks,
Mark

[plecesne]

Sounds good!

I have a few questions though. (I didn't want to post them on the JIRA if they are not relevant).

1. Will it be the MessagingException that will be sent on the error-channel?

2. Let's say I have the following flow:

Inbound CA --> SA #1 --> SA #2 --> SA #3 --> Outbound CA

CA : Channel Adapter
SA : Service Activator
--> : Direct Channel

Now, the behaviour that I want is:
- If an exception is thrown within SA #1 or SA #2, I want to redirect the failed message to errorChannel and handle that properly (store the message, and send an email, for instance)
- If an exception is thrown within SA #3 or Outbound CA due to a ConnectException or RemoteException, I want to retry 1000 times (with a delay of 10s between each try) and if it still fails, redirect the message to an errorChannel.


Is it a case that will be handled with the RetryInterceptor (JIRA 343) or is it something that could be added to this new "error-channel" attribute feature? Or is it already something possible?
If this case could be handled, this would make it the perfect "error handling kit" as I believe most cases could then be handled.

Sorry for the long thread, and thank you for caring

Pierre

[Mark Fisher]

Yes, INT-343 would be getting into that type of retry logic. In the meantime, I would recommend just adding a custom component within the pipeline that does that (you can use another service-activator I guess).

The case that we are trying to address is really more of a "catch-all" at the entry point, so it would receive the errors in case your custom retry handler fails even after all retries.

The intention is to provide something analogous to the exception mappings that one configures in web.xml for a Servlet environment (again, a "catch-all"... or "last chance" mechanism for handling errors).

Do you think this will be sufficient for now? The custom retry handler should be replaceable once we implement support for that (most likely in version 2.1).

-Mark