[jira] [Comment Edited] (CAMEL-10272) Unexpected behaviour in aggregator if recipient list is processed in parallel

["Peter Keller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-10272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15717708#comment-15717708 ] 

Peter Keller edited comment on CAMEL-10272 at 12/3/16 6:38 PM:
---------------------------------------------------------------

Alex thank you for the patch.

I updated the summary and the description of the issue so that it better suits to the actual problem. I hope that everybody is fine with this.

The analysis of our problem showed that a {{java.util.ConcurrentModificationException}} was thrown in the aggregator. A non thread safe collection was accessed concurrently in every route of the recipient list as well as in the aggregator. This explains properly the unpredictable behaviour.

Thinking about the solution I think the correct way is to pass the exception to the error handler of the main route, even if this brakes the old behaviour. Perhaps this could be controlled by a new option?



was (Author: peter keller):
Alex thank you for the patch.

I updated the title and the description of the issue so that it better suits to the actual problem. I hope that everybody is fine with this.

The analysis of our problem showed that a {{java.util.ConcurrentModificationException}} was thrown in the aggregator. A non thread safe collection was accessed concurrently in every route of the recipient list as well as in the aggregator. This explains properly the unpredictable behaviour.

Thinking about the solution I think the correct way is to pass the exception to the error handler of the main route, even if this brakes the old behaviour. Perhaps this could be controlled by a new option?


> Unexpected behaviour in aggregator if recipient list is processed in parallel
> -----------------------------------------------------------------------------
>
>                 Key: CAMEL-10272
>                 URL: https://issues.apache.org/jira/browse/CAMEL-10272
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-core
>    Affects Versions: 2.16.3, 2.17.3
>         Environment: MacOS 10.11.6, JRE 1.7.0_79
>            Reporter: Peter Keller
>
> h3. Problem
> The {{oldExchange}} is {{null}} more than once in the aggregator if a recipient list is processed in parallel.
> h3. Camel route
> In my Camel route, a recipient list is worked of in parallel:
> {code}
>  from("direct:start")
>     .to("direct:pre")
>     .recipientList().method(new MyRecipientListBuilder())
>         .stopOnException()
>         .aggregationStrategy(new MyAggregationStrategy())
>         .parallelProcessing()
>     .end()
>     .bean(new MyPostProcessor());
> {code}
> Snippet of {{MyAggregationStrategy}}:
> {code}
> @Override
> @SuppressWarnings("unchecked")
> public Exchange aggregate(final Exchange oldExchange, final Exchange newExchange) {
>     if (oldExchange == null) {
>         // this is the case more than once which is not expected!
>     }
>     // ...
> {code}
> {{oldExchange}} is null more than once which is not expected and which contradicts the contract with Camel.
> h3. Analysis
> Unfortunately, I am not able to provide a (simple) unit test for comprehending the problem. Furthermore our (complex) unit tests are not deterministic due to the root cause of the problem.
> During the processing, Camel invokes {{ParallelAggregateTask.doAggregateInternal()}}. If aggregation is not done in parallel (as it is the case in our route), this is supposed to be done synchronously:
> {code}
> protected void doAggregateInternal(AggregationStrategy strategy, AtomicExchange result, Exchange exchange) {
>     if (strategy != null) {
>         // prepare the exchanges for aggregation
>         Exchange oldExchange = result.get();
>         ExchangeHelper.prepareAggregation(oldExchange, exchange);
>         result.set(strategy.aggregate(oldExchange, exchange));
>     }
> } 
> {code}
> However, is it possible that we face a race condition in {{doAggregateInternal}} even if this method is supposed to be invoked synchronously?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)