One followup question - how did you discover the answer to this, and how
would we discover answers to problems like these ourselves? I set
IGNITE_QUIET=false, and I increased logging level in
config/java.util.logging.properties and log4j2.xml on the client side to no
avail. Is following the tree of possible code execution paths with the help
of a debugger the only option?
On Thu, Jul 11, 2024 at 12:41 PM Raymond Liu <philosob...@gmail.com> wrote:
> 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
>>>>>
>>>>
