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: cib...@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
