Hi,
What version of Camel are you using?
Other than that, not much to share other than to say that this sounds
suspiciously similar to the behavior of the flaky core tests I have been
trying to investigate the source.
Kind regards
On Tue, Jun 20, 2023 at 11:39 PM Steve973 <steve...@gmail.com> wrote:
> Hello. I am writing a better spring boot example project for the dynamic
> router eip component, and I am seeing some strange results when I route one
> million messages in a somewhat fast manner. I am generating numbers from 1
> to 1000000 and I have three routing participants:
> one accepts all numbers
> one accepts even numbers
> one accepts all odd numbers
>
> The total received count is accurate at 1000000, but the "all numbers"
> participant is some quantity below 1000000. Let's say that quantity is
> 50. Then, the "odd numbers" participant has some quantity over 500000, and
> the "even numbers" participant has some quantity over 500000. The strange
> thing is that the sum of the overages equals the difference between 1000000
> and the count received from the "all numbers" participant. In the case of
> this example, it would equal the 50 missing "all numbers" count.
>
> This is an error of about 0.005%, so I am at a loss with how I can figure
> out what is going wrong in relatively *very* few cases. Can anyone lend
> some advice about what might be going on? I am generating numbers like
> this:
>
> IntStream.rangeClosed(1, 1000000)
> .boxed()
> .map(String::valueOf)
> .forEach(sendNumberMessage);
>
> The sendNumberMessage looks like this:
>
> private final Consumer<String> sendNumberMessage = (n) ->
> producerTemplate.send(
> commandUri, ExchangeBuilder.anExchange(camelContext)
> .withHeader(KafkaConstants.KEY, n)
> .withHeader("command", PROCESS_NUMBER_COMMAND)
> .withHeader("number", n)
> .withBody(n)
> .build());
>
> As you can see, this is all running through Kafka, but I have done a
> similar test in the component code itself, while using a single JVM and the
> "direct" endpoint, and the counts will still be slightly off.
>
> I'd appreciate any pointers that any of you might have. Thanks in advance!
>
> Steve
>
--
Otavio R. Piske
http://orpiske.net
