camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: [DISCUSS] - Ignoring exceptions thrown while processing sub messages in a splitter
Date Thu, 06 Jan 2011 15:09:08 GMT
In my opinion, we should fail fast. Without a custom aggregation strategy, who's logic is application
dependent and should have all the necessary information, there is not much you can do.

For me 2) ignore the exceptions is not a good idea
1) is a better option, although a bit tricky, because the 2nd exception may be a consequence
of the first and environment/context dependent.

The best solution for me is to implement the custom aggregation strategy (as clumsy as it
is), or add validation before the split, if such a scenario is likely. We cannot really compensate
for low quality of input data, and imho the way it's implemented now is just fine.

My $0.02,

On Jan 6, 2011, at 8:57 AM, Claus Ibsen wrote:

> Hi
> Give a scenario you use a splitter EIP to process sub messages.
> from X
>  split body
>     process step 1
>     process step 2
>  end
>  to Y
> process step 1 and 2 is part of the sub processing of the sub messages.
> For example if the current message contains A,B,C,D,E and we split by
> comma. We will get 5 sub messages.
> Now suppose that this happens
> A = ok
> B = ok
> C = throws IOException
> D = ok
> E = throws UnknownOrderException
> That leaves us with several scenarios.
> Mind that all this can always be handled and 100% controlled by end
> user if you use your custom AggregationStrategy.
> In here you can control if exceptions should be ignored and whatnot.
> But that is a bit clumsy to use as you need to code Java code. So we
> are talking about options and default values on the Splitter EIP.
> Currently what happens today, is that the exception from C is
> propagated, which means that after the splitter EIP is finished.
> the IOException will be set on the current message (the input for the
> splitter), which again causes Camel to detect the exception
> and break out continue processing. Which means the message will not be
> send to Y.
> What we could do
> 1) Improve this so the splitter collects all the exceptions, so there
> is some BatchExecutionException which contains both IOException and
> UnknownOrderException.
> 2) Add new option to ignore those exceptions all together, so Camel
> will continue processing and send the message to Y.
> Mind that this scenario in fact also applies for some of the other EIP
> patterns such as
> - multicast
> - recipient list
> Also how far should we go to keep backwards compatibility?
> PS: In this example we could enable the stopOnException option which
> would cause the splitter to stop asap it detects an exception. Which
> means that it would only do
> A = ok
> B = ok
> C = throws IOException
> -- 
> Claus Ibsen
> -----------------
> FuseSource
> Email:
> Web:
> Twitter: davsclaus
> Blog:
> Author of Camel in Action:

View raw message