Hey Pavel,
That does the trick! Interestingly, if I change the return value of the
entry processor to some other POJO and I register that POJO in the
BinaryConfiguration instead of LightsaberColor, the duplicate processing
still occurs. Perhaps this is related to the cache value rather than the
return value - it just so happens that the original test used
LightsaberColor as both. Thank you very much for looking into this!
- Raymond
On Thu, Jul 11, 2024 at 8:42 AM Pavel Tupitsyn <ptupit...@apache.org> wrote:
> - Duplicate invocation happens due to automatic retry
> for UnregisteredClassException caused by return value of type
> LightsaberColor.
> - Ignite handles the exception, registers the type automatically, and
> re-runs the processor
> - This only happens once, subsequent invocations are not duplicated
> - To fix this, register the LightsaberColor explicitly in
> BinaryConfiguration. Your code should be changed like this:
>
> static class DuplicateProcessingTestConfiguration {
> @Bean
> @SneakyThrows
> public Ignite ignite(ApplicationContext applicationContext) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> cfg.setBinaryConfiguration(new
> BinaryConfiguration().setTypeConfigurations(Collections.singletonList(
> new BinaryTypeConfiguration(LightsaberColor.class.getName())
> )));
> return IgniteSpring.start(cfg, applicationContext);
> }
>
> ...
>
>
> On Wed, Jul 10, 2024 at 7:58 PM Raymond Liu <philosob...@gmail.com> wrote:
>
>> 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
>>>>
>>>
