Databases
StackOverflow2013
Postsdbo
POApache Camel: multicast with aggregation - AggregationStrategy called too often
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POApache Camel: multicast with aggregation - AggregationStrategy called too often
    primarykey
    data
    text
    <p>I have the following strange (or at least unclear to me) behaviour for a multi-cast + aggregation. Consider the following route:</p> <pre><code> from("direct:multicaster") .multicast() .to("direct:A", "direct:B") .aggregationStrategy(new AggregationStrategy() { @Override public Exchange aggregate(Exchange oldExchange, Exchange newExchange) { if (oldExchange == null) { List firstResult = newExchange.getIn().getBody(List.class); newExchange.getIn().setBody(ImmutableList.copyOf(firstResult)); return newExchange; } else { List oldResults = oldExchange.getIn().getBody(List.class); List newResults = newExchange.getIn().getBody(List.class); ImmutableList aggResult = ImmutableList.copyOf(Iterables.concat(oldResults, newResults)); oldExchange.getIn().setBody(aggResult); return oldExchange; } } }) .end() // .to("log:bla") </code></pre> <p>Essentially, this route takes an input, sends it to <code>direct:A</code> and <code>direct:B</code>, expects lists from these two endpoints and concatenates them (the comment in the last line is there for a reason I will explain later).</p> <p>Now assume that these two endpoints "return" the lists [A] and [B], respectively. If I send the message <code>M</code> to <code>direct:multicaster</code>, then the aggregator is called once with <code>oldExchange = null</code> and <code>newExchange.in.body=[A]</code>, then with <code>oldExchange.in.body=[A]</code> and <code>newExchange.out.body=[B]</code> (as it is supposed to do).</p> <p>All good up to this point. But the aggregator is called once more with <code>oldExchange.in.body=[A,B]</code> and <code>newExchange.in=M</code> (<code>M</code> is the initial message). This looks similar to an included enrichment pattern.</p> <p>You can get the expected behaviour by removing the comment in the last line, i.e. simply adding a dummy <code>to("log:bla")</code>. With this everthing behaves as expected.</p> <h3>Update: Trying (cf. the hint provided by Claus)</h3> <pre><code> .multicast() .aggregationStrategy(aggStrategy) .to("direct:A", "direct:B") .end() </code></pre> <p>and</p> <pre><code> .multicast(aggStrategy) .to("direct:A", "direct:B") .end() </code></pre> <p>both result in the same behaviour.</p> <p>What is happening here - what did I get wrong?</p> <p>thanks in advance markus </p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USfricke
    1. USfricke
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POApache Camel: multicast with aggregation - AggregationStrategy called too often
      1. This table or related slice is empty.
      1. VTUpMod
    1. COYou should have aggregationStrategy before to
      singulars
      1. POApache Camel: multicast with aggregation - AggregationStrategy called too often
      1. USClaus Ibsen
    2. COHi Claus, I added two new versions I tried with your hint and still get the same behaviour - there must be something I'm missing here
      singulars
      1. POApache Camel: multicast with aggregation - AggregationStrategy called too often
      1. USfricke
    3. COWhat version of camel do you use? Are you sure that the code pasted into the question is the exact code that is running? I can not reproduce the behavior.
      singulars
      1. POApache Camel: multicast with aggregation - AggregationStrategy called too often
      1. USsondrewe
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload