Hi Raymond, Besides the answer Pavel provided, please take into account that entry processor implementation should avoid generating random values for the entry being updated. For example, mutableEntry.setValue(rand.nextInt()) might lead to data inconsistency.
* <p> * An instance of entry processor must be stateless as it may be invoked multiple times on primary and * backup nodes in the cache. It is guaranteed that the value passed to the entry processor will be always * the same. * <p> If you need random values, please consider generating them before the invocation and passing them through additional parameters as follows: Integer randomValue = rand.nextInt(); cache.invoke(key, entryProcessor, randomValue); Thanks, Slava. ср, 10 июл. 2024 г. в 19:59, Raymond Liu <philosob...@gmail.com>: > I've only tested the real deal with 2.16, but I just ran the sample repo > test with 2.14, and the output is the same. I can test with even earlier > versions if you'd like. > > On Wed, Jul 10, 2024 at 4:08 AM Stephen Darlington <sdarling...@apache.org> > wrote: > >> Do you see the same behaviour with older versions of Ignite, or is this >> unique to 2.16? >> >> On Tue, 9 Jul 2024 at 21:34, Raymond Liu <philosob...@gmail.com> wrote: >> >>> Hi all, >>> >>> We're encountering an issue where entry processors execute twice. >>> Executing twice is a problem for us because, for easier optimization, we >>> would like our entry processors *not* to be idempotent. >>> >>> Here is a sample self-contained junit test on Github which demonstrates >>> this issue: https://github.com/Philosobyte/ignite >>> -duplicate-processing-test/blob/main/src/test/java/com/philosobyte/igniteduplicateprocessingtest/DuplicateProcessingTest.java >>> >>> >>> (in case that link doesn't work, my github username is Philosobyte and >>> the project is called "ignite-duplicate-processing-test") >>> >>> When the test is run, it will log two executions instead of just one. >>> >>> To rule out the entry processor executing on both a primary and backup >>> partition, I set the number of backups to 0. I've also set atomicityMode to >>> ATOMIC. >>> >>> Does anyone have any ideas about why this might happen? >>> >>> Thank you, >>> Raymond >>> >>
