Hi,

I encounter a severe memory peak and progressive performances degradation
problem while processing a split.
Here is a simplified schema of the route:

from("direct:fire")
    [.. stuff done here..]
    .split().method("dataFilesSplitter", "splitByPeriod")
        .unmarshal(new UniVocityTsvDataFormat())
        [.. stuff done here..]
        .to(mysql)

The bean dataFilesSplitter.splitByPeriod returns a big List<File>. Each File
object is then automagically typeconverted to string, unmarshalled and
the data is sent to a Mysql Database.

The route does what i want but the memory increases insanely and the iteration
gets slower and slower, especially during the unmarshalling..

As you can see, this use case doesn't require any kind of sub message
aggregation because the splitter is the last process at the root level of the
route.

Using .streaming() doesn't improve anything.

I've found two workarounds which resolve the problem but i doubt they are best
practices and i hardly figure what's going on under the hood:

* Adding .setBody(constant(null)) at the end of the subroute

* Create a custom aggregation strategy method for the splitter which explicitly
sets newExchange.getIn().setBody(null)

Here's the code of the aggregation strategy:

public class DisabledStrategy implements AggregationStrategy {

    public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {

        newExchange.getIn().setBody(null);

        return oldExchange;
    }
}


Is there a simpler and more logical way to achieve this ? Do i use the splitter
the right way ?

Whatever i return from the aggregate strategy the memory increase if i don't set
explicitly the body of the newExchange to null. Does the splitter stores
exchanges somewhere under the hood ?

Thanks in advance











Reply via email to