I also didn't have a use case or requirement for that. :o)
But it gives more flexibility to our users. Imagine you process some data
which are updated frequently (maybe weather forecasts). It could be no
matter, if some of the updates fail and the data are not up to date until
the next batch update
On Thu, Jan 6, 2011 at 11:03 PM, Christian Müller
wrote:
> Or could we have an option like 'stopOnExceptionCount(3)' which means stop
> on the third exception...
When would that be handy? I haven't had such a use case.
When doing parallel processing it would be harder to stop at exactly
that num
Or could we have an option like 'stopOnExceptionCount(3)' which means stop
on the third exception...
I would like to let the behavior as it is and maybe improve the
documentation if it's necessary. I didn't use the Splitter in conjunction
with the Aggregation strategy in the past. Do the Aggregator
I didn't realize that that extreme case is possible too :). Even then we could
limit the number of exceptions to at most the first N (say N=10?). But it's
again kludgy.
What if we turn stopOnException on by default in 3.0 as you propose, and just
better document how to use it for now?
Hadrian
On Thu, Jan 6, 2011 at 4:09 PM, Hadrian Zbarcea 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 g
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 th
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
