Hi
The output of the aggregate is not tied to any of its input, its a
separate new exchange, so they dont' share any unit of work etc.
So the data you want as output from the aggregator, you must then add
via the aggregation strategy
On Thu, Dec 12, 2019 at 2:56 PM wrote:
>
> Hi,
>
> Aggration s
Passing aggregation strategy to splitter would mean calling the
ProcessorDefinition#split(Expression, AggregationStrategy) rather than
split().aggregate(). Regardless.
It is indeed true that your snippet throws a stack overflow. I managed
to avoid it by either enabling parallel processing in aggre
Looking at my example code again, I am passing an Aggregator to the
Splitter, along with a completion predicate. The issue is that it appears
that when using an aggregator with a large number of split items, you
eventually run out of stack space.
On Sun, Dec 15, 2019 at 9:55 AM Jeremy Ross wrote:
My understanding is that if you pass an aggregator to the splitter that all
split elements would be aggregated as one output message. My use case
requires splits elements to be aggregated somewhat arbitrarily. E.g., if
the splitter splits a message into 1000 elements, this will be aggregated
into 2
Splitter already features an aggregation strategy as argument. By
default, it discards any modifications done to messages while
consuming them during splitter EIP. Are you sure you aren't looking
for that?
On Sun, Dec 15, 2019 at 5:53 AM Jeremy Ross wrote:
>
> Hi,
>
> I have a use case that invol
