- 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
>>>
>>
