Yeah the aggregate method in AggregationStrategy is thread-safe, and its also invoked in the "order", eg first splitted message, 2nd splitted message, ... N splitted message.
Though stop on exception can still make a little sense if the data you split is bigger than the thread pool size + queue size, in case some exception occurred, then the splitter wont have to split all messages, for then to fail after that. On Tue, Aug 20, 2013 at 11:19 AM, Aida <ai.d...@gmail.com> wrote: > Hi Claus, > > Thank you for your response, it makes sense. I suppose than then the right > way to go would be use the aggregationStrategy to propagate back the > exception. As in this case I have the same behaviour and only for checking: > threadPool shouldn´t interfere in this case, right? > > > Thanks. > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Splitter-Problem-with-stopOnException-when-using-threadPoolExecutor-tp5737562p5737570.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
