On Thu, Jan 6, 2011 at 4:09 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote: > 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. >
Yeah it could be, or suppose that you split into 100.000 sub messages, and 99.900 of those fails. Then there is too many exceptions to collect :). I also prefer to fail fast. Unfortunately the stopOnException is not enabled by default. Maybe we can turn it default in Camel 3? But again having it work the same as 2.x is also nice as its easier to upgrade. If stopOnException was enabled by default, then that 100.000 sub message example would stop when the first exception occurred. > 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, > Hadrian > > > 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: cib...@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ > > -- 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/
